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Training  Objectives 


By  the  end  of  this  training,  the  participant  should  be  able  to: 

•  Identify  and  prioritize  risks  of  failure 

•  Identify  the  function(s)  of  parts/processes,  their  inputs,  and 
associated  outputs 

•  Understand  how  supporting  tools  are  used  to  help  create  a 
FMEA 

•  Understand  the  FMEA  fields  and  line  items 

•  Evaluate  and  manage  contractors’  FMEAs 
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What  is  a  Failure  Mode  and  Effect 
Analysis  (FMEA)? 


Failure  mode  and  effect  analysis  (FMEA)  is  an  analysis  of  all  potential 

failure  modes  within  a  system.  It  provides  an  organized,  critical  analysis 

of  potential  failure  modes  and  identifies  associated  causes  and  effects. 

FMEA . 

•  can  be  performed  on  systems,  subsystems,  components,  functions, 
interfaces,  software,  and  any  process  that  has  the  potential  to  fail. 

•  is  a  risk  assessment  tool  where  possible  failure  modes,  their  effects, 
and  possible  causes  are  identified  and  ranked  according  to  their  level  of 
risk.  FMEA  is  the  most  complete  way  to  do  risk  management. 

•  is  a  widely  accepted  analysis  procedure  which  should  be  used  at  the 
initial  stages  of  development  as  well  as  throughout  the  life  cycle. 

•  is  used  as  a  foundation  for  root  cause  analysis. 
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FMEA  Defined 


Failure:  the  inability  to  produce  the  desired  output,  which  may  occur  at 
any  point  within  the  function  of  a  product. 

Failure  Mode:  The  manner  by  which  a  failure  is  observed;  it  generally 
describes  the  way  the  failure  occurs. 

Effects:  the  consequences  of  failure.  The  power  of  the  effect  will  dictate 
the  level  of  action.  Not  every  failure  needs  to  be  addressed. 

Analysis:  the  investigation  of  how  a  product  or  process  can  fail.  This 
identification  of  the  potential  failures  then  serves  to  rate: 

•  how  severe  the  effects  are. 

•  how  often  the  cause  might  occur. 

•  how  easily  we  can  prevent,  or  at  least  detect  failure. 

•  What  actions  can  be  taken  to  prevent  the  failure  in  the  future. 
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Design  FMEA-  also  known  as  DFMEA 

•  Identifies  how  a  product  fails  to  perform  its  intended  function. 

Process  FMEA  -  also  known  as  PFMEA 

•  Identifies  the  possibilities  of  incorrectly  manufacturing  or  assembling 
a  product,  or  incorrectly  performing  a  set  of  tasks. 

Proqram/Transactional  FMEA 

•  Identifies  potential  failure  modes  in  non-technical  processes 
(business  systems,  procurement  processes,  hiring  practices,  etc.)  or 
any  process  that  is  not  describing  a  product  or  the  manufacturing  or 
assembly  of  that  product. 

Other 

•  FMEA  has  been  adapted  over  the  years  to  address  failures  in  very 
specific  areas  such  as  machinery,  services,  etc. 
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A  Note  on  FMECA 


Failure  Mode  Effects  and  Criticality  Analysis  (FMECA)  is 
similar  in  method  to  FMEA  but  with  an  added  factor  called 
Criticality.  The  use  of  Criticality  to  influence  a  FMEA  is 
explained  in  MIL-STD  1629A,  which  was  canceled  on  4 
August  1998  with  no  superseding  document. 

In  light  of  the  cancellation  of  MIL-STD  1629A,  the  TARDEC 
FMEA  IPT  and  the  ARDEC  SE  AD  agree  that  FMEA  should 
be  taught  as  it  is  taught  in  industry  and  without  the  particular 
emphasis  on  Criticality.  Criticality  is  addressed  by  the  RPN  in 
FMEA.  Therefore  this  material  will  present  multiple  ways  to 
prioritize  risk  beyond  that  single  criteria. 
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FMEA  is  a  widespread  practice  used  by  various  industries. 
Different  industries  have  different  standards 

•  All  are  very  similar  in  philosophy  and  procedures 

•  They  vary  mostly  in  product  specific  details 

Different  standards  include: 

•  SAE  J-1739  Potential  Failure  Mode  and  Effects  Analysis  in 
Design  (Design  FMEA),  Potential  Failure  Mode  and  Effects 
Analysis  in  Manufacturing  and  Assembly  Process  (Process 
FMEA). 

•  SAE  ARP-5580:  “Recommended  failure  mode  and  effects 
analysis  (FMEA)  practices  for  non-automobile  applications”. 
Aerospace  Recommended  Practice 

•Automotive  Industry  Action  Group  FMEA  reference  manual: 
Automotive  applications  of  SAE  J-1739 
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How  Can  FMEA  Help  My  Program? 


•  A  DFMEA  provides  robustness  of  design. 

•  A  PFMEA  provides  robustness  of  process. 

•  A  FMEA  reused  from  a  previous  program  reduces  the 
design  time  for  the  system. 

•  Potential  failure  modes  are  identified  early  in  the  program 
and  can  be  dealt  with  up  front,  rather  than  detected  later. 

•  FMEAs  can  be  used  to  determine  the  root  cause  of 
system  or  part  failures,  once  fielded!!! 
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FMEA  is  a  proactive  approach  which  should  start  early  in 
program  life,  and  be  maintained  throughout  the  life  cycle. 
FMEA  provides  benefits  in  the  following  areas: 

1.  More  Robust  Design/Process: 

It  can  identify  the  need  to  alter  the  development  of  the  design 
and/or  the  manufacturing  process  to  prevent  major  risks, 
reduce  failure,  minimize  cost,  or  reduce  development  time. 

2.  Upfront  Risk  Identification  and  prioritization: 

FMEA  feeds  the  larger  risk  management  process.  The 
analysis  prioritizes  the  actions  that  should  be  taken  to  reduce 
risk.  It  also  highlights  where  further  actions  would  result  in 
further  risk  reduction. 

3.  Effective  Risk  Mitigation: 

Failures  can  be  identified  and  mitigated  before  they  happen. 
FMEA  helps  a  program  “do  it  right  the  first  time”,  saving  time 
and  money. 
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4.  Improved  Control  Plans: 

Design  and  process  FMEAs  can  help  to  identify  what 
design  and  process  controls  that  need  to  be  put  in  place. 

5.  Foundation  for  Root  Cause  Analysis: 

Root  cause  analysis,  failure  investigation,  and  corrective 
action  planning  time  can  be  greatly  reduced  using  FMEA. 

This  includes  diagnosing  failures  in  theatre. 

6.  Provide  Repository  for  Lessons  Learned: 

A  FMEA  is  a  living  document  and  provides  basis  for  lessons 
learned  and  best  practices  which  can  be  shared  for  use  in 
other  programs. 

7.  Increase  Reliability  and  Maintainability: 

FMEA  improves  reliability  and  maintainability  through  risk 
mitigation. 

8.  High  Reuse  for  Next  Program. 
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Why  Should  You  Care? 


Failure  Mode  and  Effects  Analysis  can  have  SIGNIFICANT 


When  correctly  executed  FMEA  reduces  costs  by 
reducing  the  possibility  of  failure. 


Doina  it  riaht  the  first  time  is  always  less  expensive  than  the  alternative. 
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rdecom^  when  to  Conduct  FMEA? 


Design  FMEA  is  a  living  document  and  should  be  initiated  before  or  at 
design  concept  finalization,  be  continually  updated  as  changes  occur,  and 
be  fundamentally  completed  before  production  drawings  are  released  for 
tooling. 

Process  FMEA  (for  manufacturing  and  assembly)  is  also  a  living  document 
and  should  be  initiated  at  the  beginning  of  the  design  stage,  and  take  into 
account  all  manufacturing  operations  of  components  and  assemblies. 

Design  and  Process  FMEA  are  similar.  Each  identifies  different  sets  of  risks 
which  need  to  be  addressed  in  different  ways.  It  is  not  sufficient  to  do  one 
without  the  other. 
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Updating  the  FMEA 


As  a  living  document,  the  FMEA  should  be  updated  at  every  opportunity.  It’s 

value  increases  with  each  new  piece  of  knowledge. 

•  FMEA  should  be  updated  at  every  design/process  change  or  after 
improvements/upgrades. 

•  FMEA  should  be  reviewed  when  performing  failure  analysis/root  cause 
analysis  to  resolve  a  field/theater  problem.  It  helps  in  identifying  root 
cause(s)  of  failure. 

•  The  FMEA  should  be  updated  when  any  new  failure  mode  or  root  cause  is 
identified  at  any  point  during  the  life  cycle  that  is  not  in  the  FMEA.  This 
allows  for  reusability  on  next  program. 

•  When  a  FMEA  is  used  for  a  similar  new  design/process,  it  should  be 
reviewed  and  revised  to  reflect  changes  in  the  new  design/process  from 
the  existing  one. 
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FMEA  and  the  Risk 
Management  Process 


The  risk  management  process  includes  the  following  key  activities, 
performed  on  a  continuous  basis: 

•  Risk  Identification 

•  Risk  Analysis 

•  Risk  Prioritization  and  Mitigation  Planning 

•  Mitigation  Plan  Implementation 

•  Risk  Tracking  and  Reporting 

FMEA  feeds  identified  and  prioritized  risks  to  Risk  Recon  for  mitigation 
planning,  implementation,  and  tracking. 

Once  a  risk  is  realized,  it  becomes  an  issue  and  is  tracked  separately  in 
the  issues  tracking  database  with  corrective  action(s)  if  necessary. 

Risk  Recon  is  an  effective  tool  for  risk  mitigation  planning,  mitigation  plan 
implementation,  risk  tracking  and  reporting. 
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rdecom^  Risk  Management  Cycle 


NOTE: 

This  slide  depicts  the 
desired  end  state  to  be 
realized  in  the  future.  The 
elements  shown  are  either 
in  development  or 
currently  exist. 
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FMEA  Thought  Process 


FMEA  development,  either  design  or  process,  uses  a 
common  approach  to  address: 

•  Potential  product  or  process  failure  to  meet  expectations 

•  Potential  effects/consequences  of  the  failure 

•  Potential  causes  of  the  failure  mode 

•  Application  of  current  controls 

•  Level  of  risk 

•  Risk  reduction 

Before  the  FMEA  document  is  started,  the  team  must 
define  the  scope  of  the  project  and  collect  existing 
information  which  is  necessary  for  an  efficient  and 
effective  FMEA  development  process. 
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FMEA  Template  Structure 


The  purpose  of  the  FMEA  template  used  is  to  organize  the 
collection  and  display  of  relevant  FMEA  information.  The 
template  address: 

•  Functions,  requirements,  and  deliverables  of  the  product 
or  process  being  analyzed, 

•  Failure  modes  when  functional  requirements  are  not  met, 

•  Effects  and  consequences  of  the  failure  mode, 

•  Potential  causes  of  the  failure  mode, 

•  Actions  and  controls  to  address  the  causes  of  the  failure 
mode, 

•  Actions  to  prevent  recurrence  of  the  failure  mode. 
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Section  B 


How  to  Prepare  for  FMEA 
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i  Who  Should  Contribute? 


A  cross  functional  team  should  be  formed  to  perform  a 
FMEA.  Members  should  include,  but  not  be  limited  to, 
representatives  from  the  following  areas: 


-  Design 

-  Validation 

-  Assembly 

-  Warranty 

-  Manufacturing 

-  Quality 

-  Testing 

-  Logistic 

-  Maintenance 

-  Safety 


-  Reliability 

-  Craftsmanship 

-  Service 

-  Materials 

-  Supplier(s) 

-  Contractor(s) 

-RAM 

-  Sustainment 

-  Human  Factors 

-  Environmental 
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rdecom^  Input  Material  for  FMEA 


Many  sources  can  provide  a  head  start  to  a  new  FMEA: 

•  Current/past  Manufacturing/Assembly  issues  related  to  the 
design 

•  Customer  contract  statement  of  requirements 

•  Assumptions  from  quote  package 

•  FMEAs  from  similar  products 

•  Engineering  specifications  and  standards 

•  Development  test  data 

•  Manufacturing,  assembly,  service,  recycle  requirements 

•  Warranty  data 

•  Prior/similar  customer  requests  for  corrective  action 

•  Lessons  learned 

•  Best  practices 

•  Benchmarking 
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Preparing  for  FMEA 


Understanding  how  something  works  is  imperative  to  finding  out  how  it 
can  fail. 


Use  proven,  thorough  approaches  to  describe  all  the  elements  of  the 
product/process: 

•  Parameter  Diagram  (P  diagram) 

•  Block  Diagram 

•  Work/product  Breakdown  Structure  (WBS) 

•  Process  Map  (PMAP) 

•  Process  Flow  Diagram 

All  these  tools  contain  elements  which  can  help  populate  certain  fields 
within  the  FMEA.  In  some  form  or  another,  they  provide  information 
about  the  item/process  step,  function,  failure  mode,  or  causes  of  failure. 

The  following  slides  explain  each  tool,  and  how  it  applies  to  the 
retractable  pen. 
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rdecoiv^  jhe  Retractable  Pen  Example 


Plunger  Assembly. 

- 1 -  - 

Retractable  Pen 


Plunger 

Cap 


Male  Female  Plunger 

Plunger  Plunger  Cap 


This  pen  will  be  used  as  an 
example  throughout  the 
remainder  of  the  class  to 
illustrate  concepts  and  conduct 
exercises. 


Comoonents 

Material 

Qtv 

1.0 

Writing  System 

r  1 

1. 1 1  -Retractable-Pen. . 

l.i.i 

Housing  Assembly 

1.1. 1.1 

Plunger  Assembly 

mu 

Clip 

ABS/PP 

1 

111.1.2 

Male  Plunger 

ABS/PP 

1 

111.1.3 

Female  Plunger 

ABS/PP 

1 

111.1.4 

PlungerCap 

ABS/PP 

1 

1.11.2 

Barrel 

ABS/PP 

1 

1.1.2 

Ink/Spring  Assembly 

1. 1.2.1 

InkTube 

112.1.1 

Tube 

ABS/PP 

1 

112.1.2 

Metal  Tip 

Brass 

1 

112.1.3 

Ball 

Tungsten  Carbide 

1 

112.1.4 

Blue  Ink 

Ink 

.1  grams 

1.12.2 

Spring 

Steel 

1 

ro 

T—i 

Nib 

ABS/PP 

1 
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Parameter  (P)  Diagram  Template 


NOISE  1: 

3iece  to  Piece 

NOISE  2: 
Change  Over 
Time 

NOISE  3: 

ustomer 

Jsage 


MOISE4: 

External 

Environment 


NOISE  5: 

System 

nteraction 


A  P-Diagram  helps  a  team  to 
understand  the  physics  related  to  the 
functions  of  the  design.  The  team 
analyzes  the  intended  inputs  and 
outputs  for  the  design  as  well  as 
those  controlled  and  uncontrolled 


INPUT 

SIGNAL 

SUB-SYSTEM 

DEAL 

FUNCTION 

0 

3 

CONTROL 

FACTORS 


factors  which  can  impact 
performance.  The  inputs  to  the 
product  and  outputs  from  the  product 
are  useful  in  identifying  error  states, 
noise  factors,  and  control  factors. 
Objective:  To  convert  the  entirety  of 
input  energy  into  desirable  outputs 
May_  be  applicable  to:  All  FMEA 

FMEA  translations: 

Error  states  =  Failure  modes 

Noise,  Control  Factor,  and  Input  Signal  =  Potential 

causes  of  failure 

Ideal  function  =  Function  or  Step 

Sub  system  =  Item  or  step  name 
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Ball  Point  Parameter  (P)  Diagram 
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rdecom r  ^  pen  Barre|  Parameter  (P)  Diagram 


NOISE  1 :  Piece  to  Piece 

Dimensional  (interference  with 
nib) 

Dimensional  (interference  with 
plunger) 

Dimensional  (interference  with 
ink) 

Material  discrepancies 


MOISE  2:  Change  Over 

rime 

Warping  of  barrel 


NOISE  3:  Customer  Usage 

Unintended  usage 
(removal/reinsertion  of  nib) 
Unintended  usage 
(removal/reinsertion  of  plunger) 


MOISE  4:  External 
Environment _ 

Humidity  (material 
changes) 

Temperature 

(expansion/contraction) 


INPUT  SIGNAL 

Press  fit  plunger 

Press  fit  nib 

Insert  ink  sub-system 

SUB-SYSTEM 

3arrel 

CONTROL  FACTORS 

Amount  of  pressure  used 
to  fit  plunger 

Amount  of  pressure  used 

to  fit  nib 

Alignment 


DEAL  FUNCTION 


Captures  ink  sub-system 
Captures  plunger  sub- 
iystem 
Captures  nib 


ERROR  STATES 

Does  not  capture  ink  sub¬ 
system 

Does  not  capture  plunger 
sub-system 
Does  not  capture  nib 
Interferes  with  retraction  of 
ink  subsystem 


NOISE  5:  System 
Interaction _ 

Too  much  force  from 
Dlunger 

Too  much  force  from  nib 
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Block  Diagram  Template 


A  block  diagram  is  an  illustration  of  a  system  that  shows  the  physical  and  logical  relationships  between  the 
components  of  the  product.  Each  block  contains  a  component  of  a  product,  and  the  lines  show  how  each  of  the 
components  interface  with  each  other. 

Objective ;  To  understand  requirements/inputs  to  the  system,  the  activities  acting  on  the  inputs,  and  the 

deliverables/outputs 

May  be  applicable  to:  Design  FMEA 


Components: 

A.  <Component1> 

B.  <Component2> 

Etc... 


Attaching  Methods: 

1.  <Method  1> 

2.  <Method2> 


Key: 

Letters  =  Components 
Numbers  =  Attaching  Methods 
-  =  Attached/Joined 

■---  =  Interfacing,  Not  Joined 
: . i  =  Not  included  in  this  Diagram 


FMEA  translations: 

Part  =  Item  name  and  number 
Attaching  method  =  Function 
“Bad”  Attaching  method  =  Failure 
mode 
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RDEcnnny  FMEA  Block  Diagram  Example 


Barrel  Clip  Plunger 
Barrel  ^  y  Cap 


Plunger  Assembly 

- 1 - 

Retractable  Pen 


Ball  Metal  _  , 

\/TiP 


Ink/Spring 

Assembly 


Blue  y 
1/ lnk  / 

_ 1 


Tube 


System  Name:  WRITING  SYSTEM  (1 .0) 

RETRACTABLE  PEN  (1.1) 


3 


COMPONENTS 

ATTACHING  METHODS 

KEY 

Letters  =  Components 

A.  Housing  Assembly 

1.  Captured 

Numbers  =  Attaching  Methods 

B.  Ink/Spring  Assembly 

2.  Compressive  Fit 

-  Attached/Joined 

C.  Nib 

3.  Captured 

■“““  =  Interfaced,  Not  Joined 

:  i  =  Not  included  in  this  FMEA 
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RDECOM 


Work  Breakdown  Structure  (WBS) 

Template 


A  Work  Breakdown  Structure  is  a  hierarchical  tool  used  to  make  a  process/product 
more  manageable.  It  divides  the  process/product  into  smaller  tasks.  It  relates  all  of 
these  tasks  with  each  other  and  with  the  final  output. 

Objective:  To  understand  the  scope  of  the  project,  and  to  see  the  process/product 
in  smaller,  more  manageable  pieces 
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RDECOM 


Process  Map  Template 


A  process  map  is  a  depiction  of  how  a  process  flows.  Assembly,  Manufacturing,  and 
Transactional  process  maps  describe  the  actionable  steps  taken  to  build  or  make 
something,  or  to  achieve  some  business  related  output.  In  all  cases  process  maps 
include  inputs  and  the  various  tasks  involved  in  turning  those  inputs  into  outputs. 
(Advanced  use  of  Functional  process  maps  can  describe  the  sequential  purposes  of 
components  working  together  to  achieve  a  desired  output.  This  information  would 
help  populate  a  Design  FMEA.) 

Objective:  To  understand  the  work  flow  of  a  process  and  the  actions  required  to  turn 
inputs  into  desirable  outputs 

May  be  applicable  to:  Process  FMEA,  Transactional  FMEA  (and  possibly  Design 
FMEA) 


Output(s): 

Y1 

Y2 

Y3 . 


Output(s): 

Y1 

Y2 


Step  #  and 
description 


Y3. 


-> 


NEXT  Step  # 
and  description 


A 


Inputs: 

Inputs: 

XI 

XI 

X2 

X2 

X3 . 

X3 . 

Unclassified 

FMEA  translations: 

Step  #  =  Process  step  # 

Description  =  Process  step  function 
“Bad”  Output  =  Failure  mode 
Input  =  Cause  of  failure 
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RDECOM 


Pen  Assembly  Process  Map 


OutpUt:  Tube  aligned  for  spring 
’  insertion 


Output 


.  Spring  aligned 
'  for  insertion 


Output: 


Completed  ink/spring 
ass’y 


Inputs: 

Plunger  ass’y 

Fixture 

Operator 


Inputs: 

Press 

Barrel 

Operator 


Inputs: 

Barrel 

Plunger  ass’y 
Fixture 
Press 
Operator 
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RDECOM 


Process  Flow  Diagram  Template 


Standard  Manufacturing  Process  Flow  Symbols 

A  process  flow  diagram 
describes  the  flow  of  the  product 
through  the  process  from 
incoming  to  outgoing.  This 
should  include  each  step  In  a 
manufacturing  or  assembly 
process  as  well  as  their  related 
outputs  (product  characteristics, 
requirements,  deliverables,  etc.) 
and  inputs  (process 
characteristics,  sources  of 
variation,  etc.).  The  details  of 
the  process  flow  depends  on  the 
stage  of  process  development 
discussion. 

Objective:  To  understand  the 
work  flow  of  a  process  and  the 
operations  required 
May_  be  applicable  to:  Process 
FMEA 

TECHNOLOGY  DRIVEN.  WARFIGHTER  FOCUSED. 


400 

F#irk  Lift  > 


/pT\ 

Fork  Lift 

Driver 

□  Inbound  Goods 

□  Organization  outside  of 
operation 

so 

Feke  Y*ke 

Pesitioh 

Check 

Ink  Assembly 
1.1.2 

□  Issue  or  Discussion  Item 

□  Inspection  /  Measurement 

OnLine 
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;  Assembly  Process  Flow 


RDECOM 


Pen  Assembly  Process  Flow 

Diagram 


Sample  -  Manufacturing  Process  Flow  Diagram 
Pen  -  Adding  Spring  to  Ink  Assembly 


RDECOM 


Suggested  Application  of  Tools 
to  Populate  a  FMEA 


Design 

FMEA 

Process 

FMEA 

Transactional 

FMEA 

Block 

Diagram 

X 

Process 

Map 

X 

X 

WBS 

X 

Parameter  (P) 
Diagram 

X 

X 

X 

Process  Flow 
Diagram 

X 
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Section  C 


How  to  Do  FMEA 
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Bottom  Line  Up  Front 


Steps  to  complete  a  FMEA 

1 .  For  each  subsystem,  component,  or  process  determine  the  ways  in  which 
the  item  functions  or  process  steps  can  go  wrong  (these  are  the  potential 
failure  modes). 

2.  For  each  failure  mode,  determine  the  effect(s)  of  the  failure. 

3.  Identify  potential  cause(s)  of  each  failure  mode. 

4.  List  the  current  controls  to  prevent  or  detect  each  cause. 

5.  Assign  a  severity  (S)  rating  to  the  effect,  and  occurrence  (O),  and  detection 
(D)  ratings  to  each  cause. 

6.  Calculate  the  risk  priority  number  (RPN).  RPN  =  S  x  O  x  D 

7.  Using  RPN  as  the  measure,  develop  mitigation  recommendations  for  high 
RPN  failures. 

8.  Take  appropriate  mitigation  actions  and  document  responsible  persons 
and  completion  date(s). 

9.  Re-evaluate  RPN  after  mitigation  action  is  complete. 

10.  Repeat  1-10  until  all  RPN  represent  accepted  risk  and  whenever  the 
process  or  product  undergoes  change,  revision,  or  unidentified  failure. 
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Item  # 


Item  name  / 
Function 


Potential 
Failure  Mode 


Potential 

c n 

CD 

o 

0) 

c/> 

c/> 

Potential  Causes 

Current 

o 

o 

o 

Current 

D 

po 

Effects  of 

< 

CD 

/  Mechanisms  of 

Design 

c 

-s 

Design 

CD 

r-h 

CD 

O 

Failure 

o' 

0) 

Failure 

Controls 

CD 

3 

Controls 

z 

< 

o' 

3 

Prevention 

O 

CD 

Detection 

lh-r  number  of'\ 
the  item  as  it  appears 
on  the  WBS  or  any 
other  document  which 
describes  the 
breakdown  of  the 
system,  sub-system, 
or  component  in 
question. 


This  field  is  useful  to  tie  the  FMEA  back  to  it’s  support 
documents.  A  WBS  example  might  look  like  “1 .1 .2.3” 
or  some  similar  format. 
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Item  # 


Item  name  / 
Function 


Potential 
Failure  Mode 


Potential 
Effects  of 
Failure 


c/> 

CD 

< 

CD 


o 

m 

c/> 

</> 


o 

a) 

o' 

3 


Potential  Causes 
/  Mechanisms  of 
Failure 


Current 

O 

o 

Current 

Design 

o 

c 

Design 

o 

0 

r-h 

7J 

Controls 

CD 

Controls 

0 

o 

Prevention 

3 

O 

CD 

Detection 

Enter  the 
name  and 
function  of 
the  item 
being 
analyzed. 


An  item  can  have  more  than  one  function,  and  therefore 
more  than  one  failure  mode. 


Examples  of  functions  include: 

-  Torque  Converter  -  Transmit  torque 

-  Corrosion  Coating  -  Resist  corrosion 

-  Bearing  Retainer  -  Retain  bearing 
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rdecom^  BaN  Design  FMEA  Exercise 


Item  # 

Item  name  / 
Function 

Potential  Failure 
Mode 

Potential  Effects 
of  Failure 

Severity 

Classification 

Potential  Causes  / 
Mechanisms  of 
Failure 

Current 

Design 

Controls 

Prevention 

Occurrence 

Current 

Design 

Controls 

Detection 

Detect 

R.P.N. 

1. 1.2.3 

Ball  /  deliver  ink 
to  paper 
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Potential  Failure  Mode 


Item  # 


Item  name  / 
Function 


Potential 
Failure  Mode 


Potential 

c n 

CD 

o 

0) 

c/> 

c/> 

Potential  Causes 

Current 

o 

o 

o 

Current 

D 

7) 

Effects  of 

< 

CD 

/  Mechanisms  of 

Design 

c 

-s 

Design 

CD 

r-h 

CD 

O 

y 

Failure 

o' 

0) 

Failure 

Controls 

CD 

3 

Controls 

z 

< 

o' 

3 

Prevention 

O 

CD 

Detection 

Describe  how 

\ 

an  item  can 

Examples  of  failure  modes: 

fail  to  meet 

-  No  torque  transmitted 

its  intended 

-  Rust  forms 

function 

-  Bearing  falls  out 

J 
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rdecom^  Potential  Effect(s)  of  Failure 


Item  # 


Item  name  / 
Function 


Potential 
Failure  Mode 


Potential 
Effects  of 
Failure 


c/> 

CD 

< 

CD 


o 

m 

c/> 

</> 


o 

a) 

o' 

3 


Potential  Causes 
/  Mechanisms  of 
Failure 


Current 

O 

o 

Current 

Design 

o 

c 

Design 

o 

0 

r-h 

7J 

Controls 

CD 

Controls 

0 

o 

Prevention 

3 

O 

CD 

Detection 

Describe 
what  the 
customer 
might  notice 
or  experience 

J 


Examples  of  effects: 

-Vehicle  cannot  move 
-Shortened  material  life  span 
-  Excessive  vibration  and  noise 


■\ 


J 
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rdecom^  BaN  Design  FMEA  Exercise 


Item  # 

Item  name  / 
Function 

Potential  Failure 
Mode 

Potential  Effects 
of  Failure 

Severity 

Classification 

Potential  Causes  / 
Mechanisms  of 
Failure 

Current 

Design 

Controls 

Prevention 

Occurrence 

Current 

Design 

Controls 

Detection 

Detect 

R.P.N. 

1. 1.2.3 

Ball  /  deliver  ink 
to  paper 

TECHNOLOGY  DRIVEN.  WARFIGHTER  FOCUSED. 


Unclassified 


44 


rdecom^  BaN  Design  FMEA  Exercise 


Item  # 

Item  name  / 
Function 

Potential  Failure 
Mode 

Potential  Effects 
of  Failure 

Severity 

Classification 

Potential  Causes  / 
Mechanisms  of 
Failure 

Current 

Design 

Controls 

Prevention 

Occurrence 

Current 

Design 

Controls 

Detection 

Detect 

R.P.N. 

1.1. 2.3 

Ball  /  deliver  ink 
to  paper 

Not  enough  ink 
delivered  to  paper 

Intermittent  line  / 
skipping 

No  ink  delivered 
to  paper 

Pen  discarded 

Too  much  ink 
delivered  to  paper 

Document  ruined 
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Potential  Causes 


Item  # 


Item  name  / 
Function 


Potential 
Failure  Mode 


Potential 

0) 

CD 

o 

0) 

c/> 

c/> 

Potential  Causes 

Current 

o 

o 

o 

Current 

D 

7) 

Effects  of 

< 

CD 

/  Mechanisms  of 

Design 

c 

-s 

Design 

CD 

r-h 

CD 

O 

y 

Failure 

o' 

0) 

Failure 

Controls 

CD 

3 

Controls 

z 

< 

o' 

3 

Prevention 

O 

CD 

Detection 

List  all 
potential 
causes  of 
the  failure 


A 


Examples  of  causes: 

-Broken  coupling 
-Improper  material  composition 
-Bearing  retainer  too  large 
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RDECOM 


Current  Design  Controls  -  Prevention 


Item  name  / 

Potential 

Potential 

c n 

CD 

o 

0) 

c/> 

c/> 

Potential  Causes 

Current 

o 

o 

o 

Current 

D 

7J 

Item  # 

Effects  of 

< 

CD 

/  Mechanisms  of 

Design 

c 

-s 

Design 

CD 

Function 

Failure  Mode 

Failure 

< 

o' 

0) 

l-K 

o' 

3 

Failure 

Controls 

Prevention 

CD 

3 

O 

CD 

Controls 

Detection 

CD 

O 

!-► 

■ 

List  the 

controls/features 

Examples  of  prevention  actions: 

"\ 

that  prevent  the 
cause  (and  in  turn 

-  Use  hardened  material 

the  failure  mode) 

-  Exceed  minimum  coating  thickness 

from  occurring,  or 
reduce  its  rate  of 
occurrence.  > 

-  Stay  within  specifications 

) 
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RDECOM 


Current  Design  Controls  -  Detection 


Item  name  / 

Potential 

Potential 

c n 

CD 

o 

0) 

c/> 

c/> 

Potential  Causes 

Current 

o 

o 

o 

Current 

D 

7J 

Item  # 

Effects  of 

< 

CD 

/  Mechanisms  of 

Design 

c 

-s 

Design 

CD 

Function 

Failure  Mode 

Failure 

< 

o' 

0) 

i-h 

o' 

3 

Failure 

Controls 

Prevention 

CD 

3 

O 

CD 

Controls 

Detection 

CD 

O 

!-► 

■ 

List  the 
controls/feature  that 
allow  the  cause  or 
the  failure  mode  to 
be  detected  as  early 
as  possible, 
preferably  before 
^effecting  function 


Examples  of  detection  actions: 

-  Batch  hardness  testing 

-  Corrosion  testing  (salt  /  humidity) 

-  Validation  testing 
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rdecom^  BaN  Design  FMEA  Exercise 


Item  # 

Item  name  / 
Function 

Potential  Failure 
Mode 

Potential  Effects 
of  Failure 

Severity 

Classification 

Potential  Causes  / 
Mechanisms  of 
Failure 

Current 

Design 

Controls 

Prevention 

Occurrence 

Current 

Design 

Controls 

Detection 

Detect 

R.P.N. 

1.1. 2.3 

Ball  /  deliver  ink 
to  paper 

Not  enough  ink 
delivered  to  paper 

Intermittent  line  / 
skipping 

No  ink  delivered 
to  paper 

Pen  discarded 

Too  much  ink 
delivered  to  paper 

Document  ruined 
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rdecom^  BaN  Design  FMEA  Exercise 


Item  # 

Item  name  / 
Function 

Potential  Failure 
Mode 

Potential  Effects 
of  Failure 

Severity 

Classification 

Potential  Causes  / 
Mechanisms  of 
Failure 

Current 

Design 

Controls 

Prevention 

Occurrence 

Current 

Design 

Controls 

Detection 

Detect 

R.P.N. 

1.1. 2.3 

Ball  /  deliver  ink 
to  paper 

Not  enough  ink 
delivered  to  paper 

Intermittent  line  / 
skipping 

Ball  diameter 
variations 

Tolerance 

specification 

Supplier  self 
certification  and 
incoming  inspection 
10  of  every  lot 

Paper  surface  finsh 
variation;  too  rough 
or  too  smooth 

Paper  surface  finish 
range  specification 

No  control 

Ball  surface  finsh 
variation 

Tolerance 

specification 

Supplier  self 
certification  and 
incoming  inspection 
10  of  every  lot 

Ball  diameter  too 
big;  blocking  flow  of 
ink 

Tolerance 

specification 

Supplier  self 
certification  and 
incoming  inspection 
10  of  every  lot 

User  does  not  exert 
sufficient  pressure 

Force  study  done 
on  users 

Test:  pressure  vs 
ink  delivery;  6  parts 
per  month  0-6  psi 

User  holds  pen  at 
extreme  angle 

Grip  angle  study 
done  on  users 

Test:  angle  vs  ink 
delivery;  6  parts  per 
month  0-90 
degrees 

No  ink  delivered 
to  paper 

Ripped  paper 

Ball  diameter  too 
big;  blocking  flow  of 
ink 

Tolerance 

specification 

Supplier  self 
certification  and 
incoming  inspection 
10  of  every  lot 

Too  much  ink 
delivered  to  paper 

Document  ruined 

Ball  diameter  too 
small 

Tolerance 

specification 

Supplier  self 
certification  and 
incoming  inspection 
10  of  every  lot 

User  exerts 
excessive  pressure 

Force  study  done 
on  users 

Test:  pressure  vs 
ink  delivery;  6  parts 
per  month  0-6  psi 

Improper  hardness 
of  ball  material 

Tolerance 

specification 

Supplier  self 
certification  and 
incoming  inspection 
10  of  every  lot 
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rdecom^  Ranking  Failure  Modes 


For  each  potential  failure,  severity,  occurrence,  and  detection 
are  evaluated  based  on  a  scale  of  1  to  10. 

The  Risk  Priority  Number  (RPN)  characterizes  a  failure  mode’s 
overall  level  of  risk  and  is  calculated  as: 

•  RPN  =  Severity  (S)  x  Occurrence  (O)  x  Detection  (D) 

The  product  of  the  RPN  equation  ranges  between  1  and  1000 
and  is  used  to  prioritize  the  potential  failure  modes  by  their 
level  of  risk  and  need  for  mitigation  action. 

Guidance  for  ranking  severity,  occurrence,  and  detection  is 
included  in  the  appendix. 
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Severity  Ranking 


z_zz_A\_\ 


Item  # 


Item  name  / 
Function 


Potential 
Failure  Mode 


Potential 
Effects  of 
Failure 


c/> 

CD 

< 

CD 


o 

m 

c/> 

</> 


o 

a) 

o' 

3 


Potential  Causes 
/  Mechanisms  of 
Failure 


Current 

O 

o 

Current 

Design 

o 

c 

Design 

o 

0 

r-h 

7J 

Controls 

CD 

Controls 

0 

o 

Prevention 

3 

O 

CD 

Detection 

Severity  is  associated  with  the  effect  of  a  given  failure  mode. 

•  Each  potential  effect  receives  a  severity  ranking. 

•  Severity  is  described  in  relation  to  how  it  affects  the  customer. 

•  Severity  is  the  most  difficult  ranking  to  later  attempt  reducing.  In  most  cases  only 
changing  the  mode  of  failure  can  change  the  effect  of  the  failure. 

Classification  refers  to  any  special  characteristics  of  the  design  or  to  high  priority 
failure  modes  like  SAFETY  or  REGULATORY  items.  Key  requirements  or  important 
product  characteristics  can  also  be  noted  here  (i.e.  KPP,  KCC,  KPC,  KSA,  etc). 
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Occurrence  Ranking 


Item  # 


Item  name  / 
Function 


Potential 
Failure  Mode 


Potential 

c n 

CD 

o 

0) 

c/> 

c/> 

Potential  Causes 

Current 

o 

o 

o 

Current 

D 

7) 

Effects  of 

< 

CD 

/  Mechanisms  of 

Design 

c 

-s 

Design 

CD 

r-h 

CD 

O 

y 

Failure 

o' 

0) 

Failure 

Controls 

CD 

3 

Controls 

z 

< 

o' 

3 

Prevention 

O 

CD 

Detection 

Occurrence  is  the  likelihood  that  a  specific  cause  will  occur,  generating  a  failure  mode. 

•  Remember  that  occurrence  relates  to  how  often  the  CAUSE  will  happen,  not  the  failure 
mode.  Therefore  similar  causes,  even  in  different  applications,  might  be  a  resource  for 
estimating  occurrence. 

•  In  determining  the  occurrence  ranking  ask  the  following  questions: 

-Are  there  any  issues  with  the  previous  design  or  a  current  like  design? 

-  Is  this  a  carryover  part,  same  application,  or  same  function  as  in  the  past?  If  so  apply 
historical  knowledge. 

-  Is  there  new  content  or  is  this  a  completely  new  design?  Similar  causes  in  other 
applications  may  help  estimate  occurrence. 

-Are  any  prevention  controls  already  in  place? 

-Are  there  any  known  quality,  reliability,  or  durability  issues  related  to  this  product? 

•  Reducing  the  occurrence  level  is  done  by  preventing  or  controlling  the  cause  of  the  failure 
mode. 

•  If  there  is  no  prevention  control,  Occurrence  is  automatically  scored  as  10. 
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Item  name  / 

Potential 

Potential 

c n 

CD 

o 

0) 

c/> 

c/> 

Potential  Causes 

Current 

o 

o 

o 

Current 

D 

7J 

Item  # 

Effects  of 

< 

CD 

/  Mechanisms  of 

Design 

c 

-s 

Design 

CD 

Function 

Failure  Mode 

Failure 

< 

o' 

0) 

i-h 

o' 

3 

Failure 

Controls 

Prevention 

CD 

3 

O 

CD 

Controls 

Detection 

CD 

O 

!-► 

■ 

Detection  is  associated  with  the  best  control  that  can  detect  the  cause  of  a  failure 
mode  or  the  failure  mode  itself.  Although  this  control  does  not  prevent  the  failure 
from  happening  it  should  identify  it  before  it  can  get  to  the  field  or  the  user. 

•  Each  detection  control  receives  a  Detection  ranking. 

•  If  multiple  controls  are  in  place,  list  all,  but  use  the  best  control  to  rank  Detect. 

•  If  there  is  no  detection  control  Detect  is  automatically  scored  as  10. 

•  In  order  to  achieve  a  lower  ranking,  the  planned  design  control  (validation, 
and/or  verification  activities)  has  to  be  improved. 
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Item  name  / 

Potential 

Potential 

c n 

CD 

o 

0) 

c/> 

c/> 

Potential  Causes 

Current 

o 

o 

o 

Current 

D 

7J 

Item  # 

Effects  of 

< 

CD 

/  Mechanisms  of 

Design 

c 

-s 

Design 

CD 

Function 

Failure  Mode 

Failure 

< 

o' 

0) 

i-h 

o' 

3 

Failure 

Controls 

Prevention 

CD 

3 

O 

CD 

Controls 

Detection 

CD 

O 

!-► 

■ 

© 


Risk  Priority  Number  (RPN) 

This  number  characterizes  the  overall  risk  of  the  failure  mode  in  question.  The  higher 
the  RPN  is  the  more  the  need  for  action  to  mitigate  or  reduce  the  risk.  RPN  is  the 
product  of  severity,  occurrence  and  detection. 

The  RPN  ranges  between  1  and  1000  for  the  purposes  of  prioritizing  mitigation 
activity. 

RPN  =  (Severity  x  Occurrence  x  Detection) 

=  S  x  O  x  D 

Not  all  potential  failure  modes  and/or  causes  of  failure  will  require  mitigation  action. 
The  higher  RPN  items  will  demand  action  while  the  lower  ones  may  go  unanswered 
due  to  time  and  resources  constraints. 
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rdecom^  BaN  Design  FMEA  Exercise 


Item  # 

Item  name  / 
Function 

Potential  Failure 
Mode 

Potential  Effects 
of  Failure 

Severity 

Classification 

Potential  Causes/ 
Mechanisms  of 
Failure 

Current 

Design 

Controls 

Prevention 

Occurrence 

Current 

Design 

Controls 

Detection 

Detect 

R.P.N. 

1.1. 2.3 

Ball  /  deliver  ink 
to  paper 

Not  enough  ink 
delivered  to  paper 

Intermittent  line  / 
skipping 

Ball  diameter 
variations 

Tolerance 

specification 

Supplier  self 
certification  and 
incoming  inspection 
10  of  every  lot 

Paper  surface  finsh 
variation:  too  rough 
or  too  smooth 

Paper  surface  finish 
range  specification 

No  control 

Ball  surface  finsh 
variation 

Tolerance 

specification 

Supplier  self 
certification  and 
incoming  inspection 
10  of  every  lot 

Ball  diameter  too 
big:  blocking  flow  of 
ink 

Tolerance 

specification 

Supplier  self 
certification  and 
incoming  inspection 
10  of  every  lot 

User  does  not  exert 
sufficient  pressure 

Force  study  done 
on  users 

Test:  pressure  vs 
ink  delivery;:  6  parts 
per  month  0-6  psi 

User  holds  pen  at 
extreme  angle 

Grip  angle  study 
done  on  users 

Test:  angle  vs  ink 
delivery:  6  parts  per 
month  0-90 
degrees 

No  ink  delivered 
to  paper 

Ripped  paper 

Ball  diameter  too 
big:  blocking  flow  of 
ink 

Tolerance 

specification 

Supplier  self 
certification  and 
incoming  inspection 
10  of  every  lot 

Too  much  ink 

delivered  to  paper 

Document  ruined 

Ball  diameter  too 
small 

Tolerance 

specification 

Supplier  self 
certification  and 
incoming  inspection 
10  of  every  lot 

User  exerts 
excessive  pressure 

Force  study  done 
on  users 

Test:  pressure  vs 
ink  delivery;  6  parts 
per  month  0-6  psi 

Improper  hardness 
of  ball  material 

Tolerance 

specification 

Supplier  self 
certification  and 
incoming  inspection 
10  of  every  lot 

TECHNOLOGY  DRIVEN.  WARFIGHTER  FOCUSED. 


Unclassified 


56 


rdecom^  BaN  Design  FMEA  Exercise 


Item  # 

Item  name  / 
Function 

Potential  Failure 
Mode 

Potential  Effects 
of  Failure 

Severity 

Classification 

Potential  Causes  / 
Mechanisms  of 
Failure 

Current 

Design 

Controls 

Prevention 

Occurrence 

Current 

Design 

Controls 

Detection 

Detect 

R.P.N. 

1. 1.2.3 

Ball  /  deliver  ink 
to  paper 

Not  enough  ink 
delivered  to  paper 

Intermittent  line  / 
skipping 

7 

Ball  diameter 
variations 

Tolerance 

specification 

1 

Supplier  self 
certification  and 
incoming  inspection 
10  of  every  lot 

2 

14 

7 

Paper  surface  finsh 
variation:  too  rough 
or  too  smooth 

Paper  surface  finish 
range  specification 

6 

No  control 

10 

420 

7 

Ball  surface  finsh 
variation 

Tolerance 

specification 

2 

Supplier  self 
certification  and 
incoming  inspection 
10  of  every  lot 

2 

28 

7 

Ball  diameter  too 
big;  blocking  flow  of 
ink 

Tolerance 

specification 

1 

Supplier  self 
certification  and 
incoming  inspection 
10  of  every  lot 

2 

14 

7 

User  does  not  exert 
sufficient  pressure 

Force  study  done 
on  users 

5 

Test:  pressure  vs 
ink  delivery:  6  parts 
per  month  0-6  psi 

4 

140 

7 

User  holds  pen  at 
extreme  angle 

Grip  angle  study 
done  on  users 

5 

Test:  angle  vs  ink 
delivery:  6  parts  per 
month  0-90 
degrees 

4 

140 

No  ink  delivered 
to  paper 

Ripped  paper 

5 

Ball  diameter  too 
big;  blocking  flow  of 
ink 

Tolerance 

specification 

1 

Supplier  self 
certification  and 
incoming  inspection 
10  of  every  lot 

2 

10 

Too  much  ink 

delivered  to  paper 

Document  ruined 

9 

Ball  diameter  too 
small 

Tolerance 

specification 

1 

Supplier  self 
certification  and 
incoming  inspection 
10  of  every  lot 

2 

18 

9 

User  exerts 
excessive  pressure 

Force  study  done 
on  users 

5 

Test:  pressure  vs 
ink  delivery;  6  parts 
per  month  0-6  psi 

4 

180 

9 

Improper  hardness 
of  ball  material 

Tolerance 

specification 

2 

Supplier  self 
certification  and 
incoming  inspection 
10  of  every  lot 

2 

36 
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RDECOM 


Barrel  Design  FMEA  Example 


Item  # 

Item  name  1 

Function 

Potential  Failure 

Mode 

Potential  Effects 

of  Failure 

Severity 

O 

U 

■ 

w 

3 

a 

a 

o 

Potential  Causes  1 

Mechanisms  of 

Failure 

Current 

Design 

Co  ntro  1  s 

Prevention 

O 

a 

a 

C 

i 

a 

o 

Current 

Design 

Controls 

Detection 

Detect 

R.P.N. 

Recommended 

Actions 

1.1. 1.2 

Barrel/Captures  ink 
su  b-system 

Does  not  capture  ink 
su  b-system 

Lose  ink  sub-system 

7 

Wrong  ink  sub¬ 
system 

Incoming  inspection 
[100  every  lot} 

6 

Material  specification 
on  detail  drawing 
and  BOM,  validated 
during  testing 

2 

64 

7 

No  plungerto 
capture  ink sub- 
syste  m 

Visual  inspection 

6 

Automated 
Assembly  check 

4 

166 

Interferes  with 

retraction  of  ink  sub¬ 
system 

Prevents  retraction 

7 

Warping  of  barrel 
[wrong  material 
selection} 

Material 

specification 

2 

Function  check 
testing 

6 

64 

7 

Warping  of  ink  sub¬ 
system  (wrong 
material  selection} 

Material 

specification 

2 

Material  specification 
on  detail  drawing 
and  BOM,  validated 
during  testing 

2 

26 

BarreVCaptures 
plunqer  sub-system 

Does  not  capture 
plunqer  sub-system 

Unfinished  pen 
assembly 

7 

Barrel  inside 
diameter  too  biq 

Tolerance 

specification 

2 

Verification  testing 

4 

56 

7 

Barrel  inside 

•diameter  too  small 

Tolerance 

specification 

2 

Verification  testing 

4 

56 

7 

Wrong  plunger 
diameter 

Tolerance 

specification 

2 

Verification  testing 

4 

56 

7 

Improper  press  fit 
(wronq  GD&T] 

GID&T 

2 

Verification  testing 

4 

26 

Lose  ink  sub-system 

7 

No  plunger  to 
capture  ink  sub¬ 
system 

Visual  inspection 

6 

Requires  visual 
signoff  by 
engineering  team 
prior  to  testing 

4 

166 

Barrel/captures  nib 

Does  not  capture  nib 

Unfinished  pen 
assembly 

7 

Barrel  inside 
diameter  too  biq 

Tolerance 

specification 

2 

Verification  testing 

4 

56 

7 

Barrel  inside 

diameter  too  small 

Tolerance 

specification 

1 

Verification  testing 

4 

26 

7 

Warping  of  barrel 
[wrong  material] 

Material 

specification 

2 

Material  specification 
on  detail  drawing 
and  BOM,  validated 
during  testing 

6 

64 

7 

Wrong  nib  diameter 

Tolerance 

specification 

1 

Verification  testing 

4 

26 

7 

Improper  press  fit 
(wrong  GD&T] 

GOST 

2 

Verification  testing 

4 

56 
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RDEcnnn >  PFMEA  (differences  from  DFMEA) 


What  we  have  just  learned  pertains  to  the  risk  involved  with  the  DESIGN  of  a  product. 
We  have  seen  how  to  identify  how  things  can  fail  to  meet  their  intended  functions  and 
how  those  failures  were  driven  by  causes  inherent  to  the  design. 

However,  just  because  something  is  designed  well  does  not  mean  it  cannot  still  fail  if  it 
is  manufactured  or  assembled  incorrectly. 


Similar  to  how  the  Design  FMEA  showed  us  the  failure  to  function,  the  Process  FMEA 
can  show  us  the  failures  in  manufacturing  and  assembly. 


Design  FMEA  (DFMEA) 
Design  failures 

•  Generates  heat 

•  Slow  acceleration 

•  Cannot  track  target 


Process  FMEA  (PFMEA) 
Manufacturing  failures 

•  Porous  casting 

•  Poorly  machined  finish 

•  Injection  molding  short  shot 


Process  FMEA  (PFMEA) 
Assembly  failures 

•  Parts  missing 

•  Parts  damaged 

•  Wrong  parts  used 


When  creating  the  PFMEA  it  is  general  practice  to  assume  that  the  DESIGN  is 
correct.  This  will  insure  that  you  do  not  accidentally  associate  design  failures  with 
manufacturing  or  assembly  failures. 
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RDEcnw >  PFMEA  (differences  from  DFMEA) 


DESIGN  FMEA 


Item  # 

Item  name  / 

Function 

Potential  Failure 

Mode 

Potential  Effects  of 

Failure 

Severity 

Classification 

Potential  Causes  / 

Mechanisms  of 

Failure 

Current 

Design 

Controls 

Prevention 

Occurrence 

Current 

Design 

Controls 

Detection 

Detect 

R.P.N. 

77 

77S 

77s i 

rv\ 

77 

777 

-0 

vLU 

HI 

VJ 

xj 

XJ 

xj 

_ 

XJ 

XJ 

V  < 

The  differences  between  the  PFMEA  and  the  DFMEA  are  minimal.  The 
descriptions  of  the  item  in  the  design  become  descriptions  of  the  steps  in 
the  process.  The  control  section  changes  in  name  but  the  intent  does  not. 
Controls  for  prevention  and  detection  are  still  applicable. 


PROCESS  FMEA 


Process  step  # 

Process  step 
function  / 
requirements 

Potential  Failure 

Mode 

Potential  Effects  of 

Failure 

Severity 

Classification 

Potential  Causes  / 
Mechanisms  of 
Failure 

Current 

Process 

Controls 

Prevention 

Occurrence 

Current 

Process 

Controls 

Detection 

Detect 

R.P.N. 

77 i 

TVS 

77 

77 

77V 

77V 

V) 

xu 

_ 

XJ 

xj 

_ 

L !u 

kli 

±LL 

XJ 

XU: 
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PLEASE  DO  NOT  LOOK  BEYOND  THIS  SLIDE! 

The  next  three  slides  contain  the  completed  PFMEA 


In  this  exercise  each  table  will  be  a  team.  Each  team  will  be  responsible  for 

performing  a  Process  FMEAon  three  steps  of  the  retractable  pen  assembly  process. 

The  instructor  will  assign  the  steps  to  each  team.  Take  no  longer  than  30  minutes. 

1 .  Choose  a  space  on  the  nearby  wall  where  your  team  can  display  your  work  or  use 
a  flip  chart  if  need  be. 

2.  Using  the  Post-it  notes  and  markers  re-create  a  PFMEA  form  (write  the  title  of 
each  PFMEA  field  on  a  Post-it  and  put  it  on  the  wall).  Refer  to  slide  59. 

3.  Refer  to  slide  36  to  determine  which  tools  will  be  helpful  to  create  a  PFMEA. 

4.  Refer  to  slide  24  to  familiarize  yourself  with  the  parts  of  the  retractable  pen. 

5.  From  slides  25-35  decide  what  information  describes  the  PROCESS  (do  not  use 
the  design  related  information). 

6.  Following  the  instructions  on  slide  38,  complete  all  steps  until  and  including  the 
calculation  of  the  RPN  (step  6). 

7.  Choose  a  representative  and  be  prepared  to  discuss  your  results  with  the  class. 
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Pen  Assembly  PFMEA 


z_zz_A\_\ 


Process  step# 

Process  step 

function  j 1 
requirements 

Potential  Failure 

Mode 

Potential  Effects  of 

Failure 

Severity 

O 

u 

w 

w 

3 

n 

91 

o 

3 

Potential  Causes  / 

Mechanisms  of 

Failure 

Current 

Process 

Controls 

Prevention 

Occurrence 

Current 

Process 

Controls 

Detection 

Detect 

P 

T3 

Z 

1 

Load  ink  tube 
vertically  into  fixture 

Tube  mis-aligned 

Spring  cannot  be 
inserted 

5 

Fixture 

features/dimensions 

incorrect 

Fixture  drawings 

3 

In  line  sensor 

2 

30 

1 

5 

Operator  not  trained 

Work  instructions 

5 

Visual  inspection 

7 

175 

1 

Tube  missing 

Spring  cannot  be 
inserted 

5 

Fixture 

features/dimensions 
incorrect  (tube  fell 
out) 

Fixture  drawings 

3 

In  line  sensor 

2 

30 

1 

5 

Operator  forgot  to 
load  tube 

Visual  inspection 

6 

No  detection  control 

10 

300 

2 

Load  spring  into 
press 

Spring  mis-aligned 

Spring  cannot  be 
inserted 

5 

Press 

features/dimensions 

incorrect 

Fixture  drawings 

3 

In  line  sensor 

2 

30 

2 

5 

Operator  not  trained 

Work  instructions 

5 

Visual  inspection 

7 

175 

2 

Spring  missing 

Spring  cannot  be 
inserted 

5 

Press 

features/dimensions 
incorrect  (spring  fell 
out) 

Fixture  drawings 

3 

In  line  sensor 

2 

30 

2 

Spring  cannot  be 
inserted 

5 

Operator  forgot  to 
load  spring 

Visual  inspection 

6 

No  detection  control 

10 

300 

3 

Press  spring  on  to 
tube 

Spring  not  fully 
pressed  onto  tube 

Spring  may  fall  off  in 
a  later  step 

7 

Press  does  not 
move  far  enough 
down 

Position  sensors 

1 

Visual  inspection 

S 

56 

3 

7 

Operator  did  not 
activate  press 

Visual  reminder 
(green  light) 

6 

No  detection  control 

10 

420 

3 

Spring  pressed  on 
to  tube  too  far 

Ink/tube  may  not 
retract/extend 

10 

KPP 

Press  travel 
incorrect 

Hard  stop  on  press 

1 

Optical  sensor 

4 

40 

3 

Spring  not  on  tube 
at  all 

Rework  needed 

3 

Spring  fell  off  of 
press  while  moving 
downward 

Part  orientation 

4 

Visual  inspection 

8 

256 

3 

Spring  pressed  on 
incorrectly  (crooked) 

Ink/tube  may  not 
retract/extend 

10 

KPP 

Fixture/press 
alignment  issue 

Verify  alignment  at 
each  shift 

2 

Hourly  audits 

6 

120 

3 

Spring  pressed  on 
incorrectly  (crooked) 

Ink/tube  cannot  be 
inserted  into 
housina 

5 

Fixture/press 
alignment  issue 

Verify  alignment  at 
each  shift 

2 

Hourly  audits 

6 

60 
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Pen  Assembly  PFMEA 


z_zz_A\_\ 


Process  step  # 

Process  step 
function  / 
requirements 

Potential  Failure 

Mode 

Potential  Effects 

of  Failure 

Severity 

O 

# 

# 

Bi 

a 

£ 

0 

3 

Potential  Causes  / 

Mechanisms  of 

Failure 

Current 

Process 

Controls 

Prevention 

0 

n 

n 

C 

i 

o 

a 

Current 

Process 

Controls 

Detection 

□ 

i 

a 

•v 

z 

4 

Load  plunger  ass'y 
td  fixture 

Plunger  assry 
misaligned 

Housing  cannot  be 
added 

5 

Fixture 

features/dime  ns  ions 
incorrect 

Fixture  drawings 

3 

In  line  sensor 

2 

30 

4 

5 

Operator  not  trained 

Work  instructions 

5 

No  detection  control 

10 

250 

4 

Plunger  ass'y 
missing 

Housing  cannot  be 
added 

5 

Fixture 

features/dime  ns  ions 
incorrect  [plunger 
assy  fell  out} 

Fixture  drawings 

3 

ii  line  sensor 

2 

30 

4 

5 

Operator  forgot  to 
load  plunger  ass'y 

Visual  inspection 

0 

No  detection  control 

10 

300 

5 

Load  barrel  on  to 

press 

Barrel  mis-aligned 

Housing  cannot  be 
added 

5 

Press 

features/dime  ns  ions 

incorrect 

Press  drawings 

3 

In  line  sensor 

2 

30 

5 

5 

Operator  not  trained 

Work  instructions 

5 

No  detection  control 

10 

250 

5 

5 

Press 

features/dime  ns  ions 
incorrect  (barrel  fell 
out) 

Press  drawings 

3 

In  line  sensor 

2 

30 

5 

5 

Operator  forgot  to 
load  barrel 

Visual  inspection 

0 

No  detection  control 

10 

300 

0 

Press  barrel  on  to 
plunger 

Barrel  not  fully 
pressed  on  to 
plunger 

Barrel  may  fall  off  in 
a  later  step 

7 

Press  does  not  move 
far  enough  down 

Position  sensors 

1 

No  detection  control 

10 

70 

0 

7 

Operator  did  not 
activate  press  fully 

Visual  reminder  (blue 
light) 

0 

No  detection  control 

10 

420 

0 

Barrel  pressed  on  to 
plunger  too  far 

Damaged 

parts/Scrap 

B 

Press  travel  incorrect 

Position  sensors 

1 

No  detection  control 

10 

BO 

0 

Barrel  not  on  plunger 
at  all 

Rework  needed 

& 

Barrel  fell  off  of  tube 

Part  orientation 

4 

No  detection  control 

10 

320 

0 

Barrel  pressed  on 
incorrectly 

Damaged 

parts/Scrap 

B 

Fixture/press 
alignment  issue 

Verify  alignment  at 
each  shift 

2 

Hourly  audits 

0 

00 
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Pen  Assembly  PFMEA 


z_zz_A\_\ 


Process  step  # 

Process  step 
function  / 
requirements 

Potential  Failure 

Mode 

Potential  Effects 

of  Failure 

w 

e 

< 

e 

1 

O 

« 

« 

31 

o 

&. 

0 

Potential  Causes  / 

Mechanisms  of 

Failure 

Current 

Process 

Controls 

Prevention 

0 

o 

a 

C 

1 

O 

e 

Current 

Process 

Controls 

Detection 

□ 

1 

a 

7* 

"0 

z 

7 

Drop  ink/spring  ass'y 
into  housing  ass'y 

Ink/spring  ass'y 
missing  from  housing 
ass'y 

Pen  could  be 

assembled  without 
writing  mechanism 

10 

KPP 

Operator  poorly 
placed  component 

Visual  inspection 

6 

No  detection  control 

ID 

000 

B 

Insert  nib  into  press 

Nih  mis-aligned 

Nib  cannot  be 

inserted 

5 

Press 

features/dime  ns  ions 

incorrect 

Press  drawings 

3 

In  line  sensor 

2 

30 

9 

Press  nib  on  to 
housing  ass'y 

Nih  not  fully  pressed 
on  to  housing 

Nib  may  fall  off  and 
ink/spring  ass’y  fall 
out  later 

7 

Press  does  not  move 
far  enough  down 

Position  sensors 

1 

No  detection  control 

10 

70 

9 

7 

Operator  did  not 
activate  press  fully 

Visual  reminder  (blue 
light) 

6 

No  detection  control 

10 

420 

9 

Nih  pressed  on  to 
housing  too  far 

Damaged 

parts/Scrap 

fl 

Press  travel  incorrect 

Position  sensors 

1 

No  detection  control 

10 

BO 

9 

Nib  not  on  housing  at 
all 

Rework  needed 

B 

Barrel  fell  off  of  tube 

Part  orientation 

4 

No  detection  control 

10 

320 

9 

Nib  pressed  on 
incorrectly 

Damaged 

parts/Scrap 

S 

Fbctu  re/press 
alignment  issue 

Verify  alignment  at 
each  shift 

2 

Hourly  audits 

6 

00 
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Take  Action  Where  Needed 


Process  step  # 

process  1  can’t  address  every  failure  - 

only  the  most  important  ones.  , 

\  Where  do  1  draw  the  line?  How  ^ 

\  Current 

J  Process 

JL  Controls 
^Prevention 

Occurrence 

Current 

Process 

Controls 

Detection 

Detect 

F 

z 

y^“  do  1  decide  where  to  focus 
YlV^  my  limited  resources? 

^Fixture  drawings 

3 

In  line  sensor 

2: 

30 

^trained 

Work  instructions 

5 

Visual  inspection 

7 

175 

\ 

^^iSture 
features/dime  ns  ions 
incorrect  (tube  fell 
out) 

Fixture  drawings 

3 

In  line  sensor 

2 

30 

5 

Operator  forgot  to 
load  tube 

Visual  inspection 

0 

No  detection  control 

10 

30O 

2 

press 

Spring  mis-aligned 

Spring  cannot  be 
inserted 

5 

Press 

featu  res/d  imensions 
incorrect 

Fixture  drawings 

3 

In  line  sensor 

2 

30 

2 

5 

Operator  not  trained 

Work  instructions 

5 

Visual  inspection 

7 

175 

2 

Spring  missing 

Spring  cannot  be 
inserted 

5 

Press 

featu  res/dime  ns  ions 
incorrect  (spring  fell 
out) 

Fixture  drawings 

3 

In  line  sensor 

2 

30 

2 

Spring  cannot  be 
inserted 

5 

Operator  forgot  to 
load  spring 

Visual  inspection 

0 

No  detection  control 

10 

300 

3 

Press  spring  on  to 
tube 

Spring  not  fully 
pressed  on  to  tube 

Spring  may  fall  off  in 
a  later  step 

7 

Press  does  not  move 
far  enough  down 

Position  sensors 

1 

Visual  inspection 

3 

50 

3 

7 

Operator  did  not 
activate  press 

Visual  reminder 
(green  light) 

0 

No  detection  control 

10 

420 

3 

Spring  pressed  on  to 
tube  too  far 

Inltftube  may  not 
retract/extend 

10 

KPP 

Press  travel  incorrect 

Hard  stop  on  press 

1 

Optical  sensor 

4 

40 

3 

Spring  not  on  tube  at 
all 

Rework  needed 

3 

Spring  fell  off  of 
press  while  moving 
downward 

Part  orientation 

4 

Visual  inspection 

3 

250 

3 

Spring  pressed  on 
incorrectly  (crooked) 

Inldtube  may  not 
retract/extend 

10 

KPP 

Fixture/press 
alignment  issue 

Verify  alignment  at 
each  shift 

2: 

Hourly  audits 

0 

120 

3 

Spring  pressed  on 
in  correctly  (crooked) 

Ink/tube  cannot  be 
inserted  into  housing 

5 

Fixture/press 
alignment  issue 

Verify  alignment  at 
each  shift 

2 

Hourly  audits 

0 

00 
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RDECOM 


Prioritizing  Failure  Modes/ 
Mitigation  Actions 


How  does  one  decide  where  to  focus  resources? 

•  Rank  order  all  failures  by  descending  RPN  and  work  on  the  highest  RPNs.  This 
most  simple  approach  is  straight  forward  but  does  not  always  indicate  where  to 
stop  working. 

•  Identify  if  a  Pareto  exists  within  the  rank  order.  Unlike  a  simple  rank  order,  a 
Pareto  has  a  natural  boundary  between  higher  and  lower  RPNs.  This  suggests  a 
goal  to  work  to. 

•  Create  a  chart  of  RPN  by  grouped  causes  and  again  look  for  the  Pareto.  Multiple 
similar  causes  might  be  mitigated  using  the  same  action.  This  approach  is 
usually  the  most  economical. 

•  Prioritize  using  severity  only,  or  severity  with  occurrence  together.  If  severity  (or 
severity  +  occurrence)  alone  was  of  great  concern  it  could  be  used  to  dictate  the 
focus  of  mitigation  actions. 
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Take  Action  Where  Needed 


A  chart  can  be  made  of  RPN  versus  cause.  Without  a  Pareto,  the  easiest 
way  to  decide  what  to  work  on  is  to  simply  sort  by  RPN  and  address  the 
highest  items.  In  a  simple  rank  order  chart  the  RPN  falls  (descends)  by 
even,  somewhat  linear  steps. 


700 


600 


500 


400  - 


Chart  of  RPN  by  individual  causes 


The  main  problem  with  a  chart  like  this  is 
deciding  where  to  stop.  Usually  the 
amount  of  resources  available  will  dictate 
how  many  causes  can  be  addressed. 


(~)C— I 1  i 


R.P.N. 


Poor  Press  not  Press  not  Press  not  Barrel  fell  Barrel  fell  Operator  Operator  Operator  Spring 

placement  activated  activated  activated  off  off  forgets  forgets  forgets  falls  off 

fully  fully  tube  spring  plunger 
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W  Take  Action  Where  Needed 


If  a  Pareto  exists  then  the  80/20  rule  starts  to  apply,  meaning  that  the 
majority  of  our  concern  can  be  eliminated  by  addressing  the  relatively  few 
but  very  potent  top  items. 


Pareto  chart  of  RPN  by  individual  causes 


^  & 
ft 


In  a  true  Pareto  there  is  an  obvious  step  down  after 
the  first  few  large  RPN  items.  In  this  case  it  is  not  only 
easy  to  see  what  to  work  on,  but  also  where  to  stop 
working. 


B  ■  ■  ■ 


R.P.N. 


A^  A^  ft  sft 

*  J?  ft*  -ft> 

oft  ift  <0>  J2T  jft 

/  4*  ^  ^ 

/o-  xp  ^ 


(5s 


c? 


£ 


d? 


ft 


CP 


<ft 

ft 


ft 
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Take  Action  Where  Needed 


If  another  way  is  desired  to  identify  a  Pareto  and  get  the  most  risk  mitigation  for  the 
money,  causes  that  are  similar  and  that  might  receive  the  same  controls  can  be 
grouped.  This  is  a  “kill  many  birds  with  the  same  stone”  approach.  Cause  groups 
are  comprised  of  many  similar  causes  found  throughout  the  entire  FMEA. 
Individually  their  RPN  rankings  might  be  low,  but  when  combined  into  a  group  they 
can  add  up  substantially. 


Addressing 
anything  that 
has  to  do 
with 

“operator 
error”  has  a 
HUGE 
impact! 


4500 

4000 

3500 

3000 

2500 

2000 

1500 

1000 

500 

0 


Pareto  chart  of  RPN  by  cause  group 


T 


Operator  error  Parts  falling  off 


This  group  represents  all 
causes  that  have  anything  to  do 
with  operators  (poor  part 
placement,  activation  of  the 
press,  lack  of  training,  etc). 

■  R.P.N. 


Travel  Alignment  Fixture/press 
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Recommended  Action 


Recommended  Actions  Plan 


Responsibility  &  Target  Completion 
Date 


Action  R 

esuli 

ts 

Actions  Taken 

Severity 

Occur 

Detection 

R.P.N. 

;  \ 

Describe 

what  actions 
are  needed  to 
reduce  the 
overall  RPN 

_ J 


Reducing  RPN  can  be  done  by: 

-  Decreasing  the  severity 

-  Reducing  the  likelihood  of  occurrence 

-Improving  detection  methods 
_ _ _ / 
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Recommended  Action 


The  primary  objective  of  the  recommended  action  is  to 
reduce  risk  thereby  reducing  the  possibility  of  failure.  This  in 
turn  increases  customer  satisfaction  and  lowers  cost. 

The  actual  intent  of  any  recommended  action  is  to  reduce  the 
rankings  of  any  of  the  following:  severity,  occurrence,  and 
detection. 

If  the  RPN  value  is  below  the  agreed  to  threshold,  then  the 
team  can  enter  “none”  for  the  recommended  action. 
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RDECOM 


Responsibility  &  Target 
Completion  Date 


Action  Results 

Recommended  Actions  Plan 

Responsibility  &  Target  Completion 
Date 

Crt 

o 

O 

a 

i— Sh 

73 

Actions  Taken 

< 

o 

o 

o 

o 

o 

TJ 

-I 

3 

E 

"i 

A 

o' 

Z 

3 

Name  who 
will  take 
action  and 
when 


Recommended  actions: 

-need  completion  dates 

-can  be  taken  by  FMEAteam  members,  or.. 

-can  be  taken  by  other  parties  with  a  FMEA 
team  member  being  responsible 
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rdecom^  Target  Completion  Date 


As  simple  as  it  seems  the  Target  Completion  Date  should  be 

paid  careful  attention  to: 

•  This  is  the  estimated  date  when  the  team  agrees  the 
recommended  action  should  be  completed.  If  it  looks  like 
the  date  will  be  missed,  then  the  team  should  revise  the 
date. 

Traceability: 

•  If  the  person  responsible  leaves  the  core  team  prior  to  the 
completion  of  the  recommended  action,  then  another  core 
team  member  should  be  assigned. 

•  If  the  person  responsible  leaves  the  core  team  after 
completion  of  the  recommended  action,  then  that  persons 
name  stays  on  the  document. 
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Action  Taken  and 
Effective  Date 


Action  Results 

Recommended  Actions  Plan 

Responsibility  &  Target  Completion 
Date 

Crt 

o 

O 

a 

i— Sh 

33 

Actions  Taken 

< 

o 

o 

o 

o 

o 

TJ 

-I 

3 

E 

■n 

ft 

o' 

Z 

3 

v 


\ 

Actions  taken: 

Describe 

A  1  A  1 

-Are  not  always  identical  to  the 

ACTUAL 

recommendations  (time  and  resources  limited) 

actions  taken 

-  May  not  get  done  when  expected 

J 
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Action  Results 

Recommended  Actions  Plan 

Responsibility  &  Target  Completion 
Date 

Crt 

o 

O 

a 

i— Sh 

73 

Actions  Taken 

< 

o 

o 

o 

o 

o 

TJ 

-I 

3 

E 

"i 

ft 

o' 

Z 

3 

Recalculate 

New 

RPN 


-  Once  the  action  has  been  executed  the  team 
must  indicate  new  severity,  occurrence,  and 
detection  rankings  where  applicable 

-  Recalculate  the  RPN  after  re-ranking 
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RDECOM 


Ball  Design  FMEA  Exercise 


Item  t 

Item  name  1 

Function 

Potential  Failure 

Mode 

Potential 

Effects  of 

Failure 

40 

m 

c 

2 

Classification 

Potential 

Causes  f 

Mechanisms  of 

Failure 

Current 

Design 

Controls 

Prevention 

Occurrence 

Current 

Design 

Controls 

Detection 

Detect 

R.P.N.  ^ 

Responsibilitg  b 

Ad 

tion  Rt 

‘suits 

Actio^^^^^ 

..ifinpl^tion  Date 

ActionsTaT^P 

Cfl 

o 

ft 

D 

m 

5 

o 

R.P.N. 

1.1. 2. 3 

Ball  1  deliver  ink 
to  paper 

Not  enough  ink 
delivered  to 

paper 

Intermittent  line 
f  skipping 

7 

Ball  diameter 
variations 

Tolerance 

specification 

1 

Supplier  self 
certification  and 
incoming  inspection 
10  of  every  lot 

^^4 

7 

Paper  surface  finsh 
variation;  too  rough 
or  too  smooth 

Paper  surface  finish 
range  specification 

6 

Wo  control 

10 

420 

Study  coefficient  of 
friction  us  ink 
delivery  amount 

G.  Ratajczak  11 
Nov  2011 

Studg  complete  - 
must  control  ball 

surface  finish 

7 

1 

10 

70 

7 

Ball  surface  finsh 
variation 

Tolerance 

specification 

2 

Supplier  self 
certification  and 
incoming  inspection 
10  of  every  lot 

20 

7 

Ball  diameter  too  big; 
blocking  flow  of  ink 

Tolerance 

specification 

1 

Supplier  self 
certification  and 
incoming  inspection 
10  of  every  lot 

2 

7 

User  does  not  ewert 
sufficient  pressure 

Force  study  done  on 
users 

5 

Test:  pressure  us  ink 
delivery;  6  parts  per 
month  0-6  psi 

4 

7 

User  holds  pen  at 
ewtreme  angle 

Grip  angle  study 
done  on  users 

5 

Test:  angle  us  ink 
delivery;  6  parts  per 
month  0  -  90  degrees 

4  A 

No  ink  delivered 

to  paper 

Ripped  paper 

5 

Ball  diameter  too  big; 
blocking  flow  of  ink 

Tolerance 

specification 

1 

Supplier  self 
certification  and 
incoming  inspection 
10  of  every  lot 

Too  much  ink 

delivered  to 

paper 

Document  ruined 

9 

Ball  diameter  too 
small 

Tolerance 

specification 

1 

Supplier  self 
certification  and  i 
incoming  inspection 
10  of  every  lot  ^ 

W  18 

9 

User  exerts 
excessive  pressure 

Force  study  done  on 
users 

5 

Test: 

parts^^^^^^^v 

month  0-6 

180 

9 

Improper  hardness 
of  ball  material 

Tolerance 

specification 

2 

Suppl^^^^^H 

r  c  a  ... 

incoming 

38 

Recommended 

Actions 

Responsibility  Si 
Target 

Completion  Date 

Action  Results 

Actions  Taken 

Severity 

Occur 

Detection 

R.P.N. 

Study  coefficient  of 
friction  vs  ink 
delivery  amount 

G.  Ralajczak  11 
Nov  2011 

Study  complete  - 
must  control  ball 
surface  finish 

7 

1 

10 

70 
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RDEcnnny  Transactional  FMEA  Example 


Depicted  here  is  the  flow  of  a  process 
which  has  nothing  to  do  with  how  a 
product  works  nor  how  it  is  put 
together,  but  instead  how  “business” 
gets  done.  These  “transactional” 
processes  are  non-technical  and  have 
more  to  do  with  documents  and  data 
than  components  and  machines. 


YES 


Insert  Requirement 
,  into  Cell  Directly 
Below  Working  Group 
(Row)  and  make  bold 


Inputs: 

•CDD  Requirements 
Analysis  Matrix 
•VRS  Team 
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rdecom^  Transactional  FMEA  Example 


Using  the  PFMEAform  is  most  appropriate  when  risk  reducing  transactional  processes  because 
like  assembly  processes  they  are  typically  a  combination  of  STEPS.  Transactional  processes 
are  often  overlooked  in  risk  reduction  although  the  consequences  of  their  failure  still  equate  to 
cost  and  time.  Whether  new  or  already  in  use,  transactional  processes  should  be  understood 
and  risk  reduced  using  all  the  tools  you  have  just  learned. 


Process  step  function  / 
requirements 

Potential  Failure  Mode 

Potential  Effects  of  Failure 

Severity 

Classification 

Potential  Causes  /  Mechanisms  of 
Failure 

Current 

Process 

Controls 

Prevention 

Occurrence 

Current 

Process 

Controls 

Detection 

Detect 

R.P.N. 

Recommended  Actions 

Insert  Requirement  into  Cell  Directly 
Below  Working  Group  (Row)  and 
Make  Bold 

Similar  req’t  placed  in  incorrect  row. 
but  did  not  overwrite  anything 

Duplication  of  superset 
requirements,  resulting  in 
additional  work  /  schedule  delay 

7 

VRS  Team  human  error 

None 

10 

Deconfliction  process 
forces  reconsideration 
of  stand  alone  req’ts 

1 

70 

Insert  Requirement  into  Cell  Directly 
Below  Working  Group  (Row)  and 
Make  Bold 

Similar  req’t  placed  directly  below 
working  group  row.  but  overwrites  an 
existing  req’t 

Incorrect  superset  requirement 
generated  (overwritten  req’t 
present  in  other  platforms,  but 
was  the  driving  req’t  for  a 
superset  req’t) 

8 

VRS  Team  human  error 

None 

10 

None 

10 

800 

Count  number  of  req’ts  for  each 
platform  before  commonizing  req’ts 
within  that  platform.  Check  req’t  count 
after  commonizing  req’ts  to  ensure  that 
the  number  does  not  chanqe 

Insert  Requirement  into  Cell  Directly 
Below  Working  Group  (Row)  and 
Make  Bold 

Similar  req’t  placed  directly  below 
working  group  row,  but  overwrites  an 
existing  req’t 

SIL  lacks  capability  in  question 
(overwritten  req’t  not  present  in 
other  platforms,  so  entire 
capability  is  lost) 

10 

VRS  Team  human  error 

None 

10 

None 

10 

1000 

Count  number  of  req’ts  for  each 
platform  before  commonizing  req’ts 
within  that  platform.  Check  req’t  count 
after  commonizing  req’ts  to  ensure  that 
the  number  does  not  chanqe. 

Insert  Requirement  into  Cell  Directly 
Below  Working  Group  (Row)  and 
Make  Bold 

Similar  req’t  not  moved  at  all 

Incorrect  superset  requirement 
generated 

8 

VRS  Team  human  error 

None 

10 

Continued  req’t 
commonization  will 
ensure  the  non-moved 
req’t  is  assessed  for 
commonality  (which 
would  catch  the 
duplicate  req't) 

1 

80 

Insert  Requirement  into  Cell  Directly 
Below  Working  Group  (Row)  and 
Make  Bold 

Similar  req’t  not  moved  at  all 

Duplication  of  superset 
requirements,  resulting  in 
additional  work  /  schedule  delay 

7 

VRS  Team  human  error 

None 

10 

Continued  req’t 
commonization  will 
ensure  the  non-moved 
req’t  is  assessed  for 
commonality  (which 
would  catch  the 
duplicate  req’t) 

1 

70 

Insert  Requirement  into  Cell  Directly 
Below  Working  Group  (Row)  and 
Make  Bold 

Partial  move  of  similar  req’t  (failure  to 
move  comments,  rationale,  and 
traceability  when  relocating  a  similar 
req’t) 

Difficulty  creating  superset 
requirement  due  to  missing 
details 

5 

VRS  Team  human  error 

None 

10 

None 

10 

500 

Upon  completion  of  requirement 
commonization  for  a  platform,  expand 
the  collapsed  column  and  look  for  rows 
that  have  comments,  rationale,  and/or 
traceability  without  an  associated  req't 

Insert  Requirement  into  Cell  Directly 
Below  Working  Group  (Row)  and 
Make  Bold 

Req’t  copied  and  pasted,  instead  of 
cut  and  pasted 

Duplication  of  superset 
requirements,  resulting  in 
additional  work  /  schedule  delay 

7 

VRS  Team  human  error 

None 

10 

Continued  req’t 
commonization  will 
ensure  the  duplicate 
req’t  is  assessed  for 
commonality  (which 
would  catch  the 

1 

70 

Count  number  of  req’ts  for  each 
platform  before  commonizing  req’ts 
within  that  platform.  Check  req’t  count 
after  commonizing  req’ts  to  ensure  that 
the  number  does  not  change. 
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RDECOM 


Using  FMEA  for  Root  Cause 

Analysis 


In  the  event  that  a  failure  mode  is  encountered,  the  FMEA  can  be  the  first 
source  for  reactive  problem  solving. 


Control  has  failed 
-  find  out  why, 
improve  control, 
update  FMEA. 


Root  cause  is  not 
on  FMEA.  Use 
other  methods  to 
identify  root 
cause. 

Recalculate  RPN 
and  update 
FMEA. 

i 
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Using  FMEA  for  Root  Cause 
Analysis  -  Example 


Situation:  Retractable  pen  field  failure:  returned  pen  with  loose/falling  out  nib 

Suggested  approach  - 

•  Examine  both  DFMEA  and  PFMEA  for  possible  design,  manufacturing  or  assembly 
causes  for  the  loose  nib. 

•  If  the  failure  mode  or  its  effect  are  not  present  on  FMEA  - 

•  Use  P-diagram,  block  diagram,  process  map  and  similar  tools  to  identify  this 
failure  mode  and  then  its  cause.  Execute  formal  problem  solving. 

•  If  the  failure  mode  or  its  effect  are  present  on  FMEA  look  in  the  cause  column  - 

•  Possible  design  causes  that  could  cause  loose  nib  are:  wrong  barrel  or  nib 
diameter,  wrong  GD  &T  (geometric  dimensioning  and  tolerance)  between  barrel 
and  nib,  warping  of  material  due  to  wrong  material  selection. 

•  Investigate  unintended  usage  (removal  and  reinsertion  of  nib)  which  may  wear 
material  out. 

•  Possible  process  causes  that  could  cause  loose  nib  are:  not  enough  pressure 
for  insertion  (nib  not  fully  seated),  misalignment  between  barrel  and  nib. 

•  Verify  your  findings  by  testing  and/or  re-creating  the  failure. 

•  If  the  root  cause  you  found  is  not  in  the  FMEA,  update  the  FMEA,  issues,  and 
lessons  learned  databases. 
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rdecom^  Ground  Vehicle  (G V)  -  Example 


•  Failure:  A  GV  Air  Conditioning  (A/C)  condenser  fan  motor  was  failing  in  OIF. 
When  it  failed,  the  vehicles  had  no  A/C  and  were  unusable  in  high  ambient 
conditions.  Power  to  the  motors  was  confirmed  to  be  present,  they  just 
would  not  function. 

•  Parts  were  shipped  back  to  the  US  from  Iraq  and  torn  down.  Upon 
inspection,  the  PC  board  showed  damage  and  charring  due  to  over¬ 
current  situation. 

•  A  probable  failure  was  determined  but  could  not  be  verified  as  the  root 
cause  since  the  supplier  did  not  have  a  FMEA  for  the  part.  Duplication 
of  failure  testing  commenced  and  took  three  months  to  complete  before 
the  root  cause  was  acknowledged.  This  could  have  been  shortened  to 
days  if  a  FMEA  existed. 

•  Lesson  Learned  -  For  critical  subsystems,  a  FMEA  should  be  contractually 
required  from  the  tier  1 ,  who  should  enlist  the  lower  tier  suppliers  to  create 
and  maintain  to  shorten  the  duration  of  root  cause  analysis  and  corrective 
action. 

•  Corrective  Action  -  For  this  part,  a  FMEA  was  created  to  ensure  the 
corrective  action  would  not  create  additional  problems.  Generic  FMEA 
contractual  language  has  been  developed  for  future  use. 
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Root  Cause  Analysis  -  Partial 
Design  FMEA  Shown 


System:  A/C  Condenser  Fan  System  Design  Responsibility  : 

Subsystem:  A/C  Condenser  Fan  Kick  off  Date  : 

Component:  - 
Model  Year  /  Vehicle  (s)  : 

Core  Team: 

Support: 


Item 

^^^^^unction 

Potential  Failure 

Mode 

Potential  Effects  of 

Failure 

Severity 

Potential  Causes  / 

Mechanisms  of  Failure 

Occurrence 

Current  Controls 

Prevention 

Controls 

Detection  Controls 

[1]  The  fan  subsystem  shall  meet  airflow 
requirements  (6  in.  WCaP  1500  CFM  for  XXXX) 

[1.1]  The  fan  subsystem 
does  not  meet  airflow 
requirements  {6  in.  WCaP 
1500  CFM  for  XXXX) 

Complete  loss  of  airflow 
(8) 

8 

[1.1.1]  Loss  of  source  current  / 
voltage 

-  Blown  fuse 

-  Broken  wire 

4 

-  Conduct  a  worst  case 
circuit  analysis  of  vehicle 
control  circuit 

-  Compare  fuse  capacity 
to  in-rush  current  and  stall 
current  during  high 
ambient  temperature 
conditions 

-  Review  wire  routing, 
attachment  and  shielding 

-  Yuma  -  Test  vehicle 

-  Hew  Yuma  -  test 
vehicle 

Partial  loss  of  airflow 
{€) 

[1.1.2]  Over-voltage  /  Transients 

3 

-  FW  3  -  Electrical 
Requirements  and 
characterization 

-  FW  4  -  Body  Fan 
Requirement  validation 

-  Yuma  -  Test  vehicle 

-  New  Yuma  -  test 
vehicle 

[1.13]  Control  circuit  malfunction 

5 

-  FW  3  -  Electrical 
Requirements  and 
characterization 

-  FW  4  -  Body  Fan 
Requirement  validation 

-  Yuma  -  Test  vehicle 

-  Hew  Yuma  -  test 
vehicle 

[1.1.4]  Mechanical 
impedence/obstruction  that  either 
slows  or  stops  the  rotation  of  the 
impeller  (internal/extemal 
contamination) 

€ 

-  DTL  1  -  Hot  Clean 

-  DTL  2  -  Hot  +  Dust 

-  DTL  3  -  Hot  + 

Imbalance 

-  DTL  4  -  Hot  +  Dust  + 
Road  load  /  Resonance 

-  FW  1  -  Fan  imbalance 
cycling 

-  FW  2  -  Dust 

-  Yuma  -  Test  vehicle 

-  Hew  Yuma  -  test 
vehicle 

-  Airflow  verification 
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RDECOM 


Using  FMEA  for  Root  Cause 
Analysis  -  Exercise 


Situation:  A  group  of  retractable  pens  were  returned  to  your 
company  with  complaints  of  malfunction  (not  clicking  and  ink 
tube  not  staying  out  in  the  writing  position) 

Your  team  is  given  one  good  pen  (for  reference)  and  one 
malfunctioning  pen 


Instructions  -  spend  no  more  than  30  minutes  to: 

•Use  the  pen  assembly  PFMEA  to  perform  Root  Cause 
Analysis  (for  this  example  the  DFMEA  is  not  used;  in 
reality  you  should  always  look  at  both).  Follow  the 
flowchart  on  slide  78. 

•Try  to  verify  the  root  cause  by  re-creating  the  failure 

•Recommend  any  changes  to  the  assembly  PFMEA  if 
necessary  to  clarify  this  failure  mode 

•Choose  a  representative  to  present  your  findings 
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Section  D 


Transitioning  to  Risk  Recon  & 
Managing  Contractors’  FMEAs 
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rdecom^  FMEA  and  Risk  Management 


Although  FMEA  is  often  used  in  industry  to  manage  the  actions  that  will 
mitigate  failure,  it  does  not  allow  enough  room  for  detailed  mitigation 
planning.  The  Government  has  a  process  for  managing  risks  and 
mitigation  plans  and  documents  using  the  Army  owned  risk  management 
tool  called  Risk  Recon. 

•  Risk  Recon  is  for  implementing,  tracking,  and  reporting  the  progress  of 
the  recommended  mitigation  plans/actions  created  in  the  FMEA.  In  this 
way  FMEA  is  a  necessary  input  to  Risk  Recon. 

•  Information  from  the  FMEA  fields  can  be  transferred  to  populate  the  risk 
info  sheet  and  mitigation  plans  in  Risk  Recon. 

•  Periodic  reports  can  be  generated  by  Risk  Recon  for  management 
notification  on  mitigation  plan  implementation,  progress,  and  status. 

•  Risk  Recon  is  capable  of  electronic  tracking  and  providing  notifications 
to  team  members  and  persons  responsible  for  executing  mitigation 
actions. 

•  Successful  risk  mitigation  reduces  the  RPN.  Once  a  risk  is  mitigated,  or 
an  issue  corrected,  this  information  gets  documented  in  the  FMEA  and 
the  RPN  is  rescored. 
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- - Transferring  Risks  from  FMEA  to 

Risk  Management/Risk  Recon 


In  risk  management  Risk  Recon  ranks  risk  by  using  two  parameters  only: 

•  consequence  (  correlates  to  severity) 

•  likelihood  (  correlates  occurrence) 

Similar  to  FMEA  high  risk  is  associated  to  failures  with  high  scores  on 
consequence  and  likelihood. 

To  transfer  rankings  from  FMEA  to  Risk  Management/Risk  Recon,  we 
translate  the  FMEA  1-10  severity  and  occurrence  scales  to  the  Risk 
Recon  1-5  consequence  and  likelihood  scales.  This  translation  is 
provided  on  the  ranking  tables  in  the  appendix. 

Risk  Recon  is  a  two  dimensional  view  of  risk  since  detection  is  not 
transferred  from  the  FMEA.  However,  failures  which  were  significant  due 
to  the  inclusion  of  poor  detection  rankings  on  the  FMEA  cannot  be 
ignored  in  Risk  Recon.  To  manage  risk  completely  transfer  ALL  high  risk 
failures  and  their  mitigation  actions  to  Risk  Recon. 
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i  Government  Contracts  and  FMEA 


Many  government  products  are  designed,  manufactured,  and  assembled  by 
contractors  through  written  contracts. 

We  have  learned  that  without  some  structured  approach  to  reducing  risk, 
such  as  FMEA,  failures  with  various  levels  of  effect  can  and  will  result.  This 
is  unacceptable  to  the  Warfighter. 

Therefore  the  Government  should  expect  contractors  to  complete  any  and 
all  appropriate  FMEAs  needed  to  risk  reduce  a  product. 


Government  contracts  need  to  be  written  such  that  the  FMEA  and  its 
supporting  documents  will  be  able  to  be  utilized,  shared,  and  audited  by  the 
Government.  This  will  insure  that  failures  are  minimized,  and  costs  stay 
within  expectations. 


Recommend  using  TARDEC  FMEA  Templates,  Ranking  Tables  with  two 
scales,  and  FMEA  evaluation  Check  Lists  for  DFMEA  &  PFMEA 
customized  to  DoD  systems. 
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RDECOM 


Suggested  Government  Contracts’ 
Language  for  FMEA 


•  Example:  Design  FMEA  Language 

The  contractor  shall  conduct  and  provide  Design  Failure  Mode  and  Effects 
Analysis  (DFMEA)  on  all  critical  items  and  key  subsystems.  For  subcontractor- 
sourced  critical  items  or  key  subsystems,  the  contractor  shall  contract  sub¬ 
contractor  to  complete  and  deliver  applicable  DFMEA.  The  information  used 
to  create  this  Contract  Data  Requirement  List  (CDRL)  shall  be  available  to  the 
Government  and  discussed  at  IPT  meetings  as  well  as  major  reviews  in 
accordance  with  the  Government  provided  Integrated  Master  Plan  (IMP).  The 
contractor  and  their  suppliers  shall  use  the  AIAG  FMEA  manual  (latest  edition) 
as  a  guide  to  create  the  DFMEAs  and  use  the  government  provided  TARDEC 
DFMEA  Severity,  Consequence  and  Likelihood  guides  for  ranking. 


Design  FMEAs  for  other  items  (non-critical  items,  non-key  subsystems)  shall 
be  made  available  upon  Government  request.  The  DFMEA  and  related 
documents  (e.g.  block  diagram,  WBS,  FTA,  P-diagram)  are  living  documents. 

The  contractor  shall  update  these  documents  to  reflect  lessons  learned, 
updated  reliability  predictions,  and  corrective  actions. 
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nnrnnnn  >  Suggested  Government  Contracts’ 


Lanquaqe  for  FMEA 


•  Example:  Process  FMEA  Language  (for  manufacturing  and/or  assembly 
process) 

The  contractor  shall  create  PFMEA's  for  all  processes  (manufacturing  and 
assembly)  necessary  to  build  the  specific  Government  product/vehicle.  The 
contractor  shall  provide  all  key  subsystem  PFMEAs  to  the  Government.  The 
information  used  to  create  this  Contract  Data  Requirement  List  (CDRL)  shall 
be  available  to  the  Government  and  discussed  at  IPT  meetings  as  well  as 
major  reviews  in  accordance  with  the  Government  provided  IMP.  The 
contractor  and  their  suppliers  shall  use  AIAG  FMEA  manual  (latest  edition)  as 
a  guide  to  create  the  PFMEAs  and  use  the  government  provided  TARDEC 
PFMEA  Severity,  Consequence  and  Likelihood  guides  for  ranking.  The  PFMEA's 
are  living  documents  and  shall  be  traceable  to  the  engineering  change  level  & 
process  changes,  and  shall  be  included  in  the  configuration  management 
change  process. 

Process  FMEAs  for  other  items  (non-critical  items,  non-key  subsystems)  shall 
be  made  available  upon  Government  request.  The  PFMEA  and  related 
documents  (e.g.  process  map,  process  flow  diagram,  FTA)  are  living 
documents.  The  contractor  shall  update  these  documents  to  reflect  lessons 
learned,  updated  reliability  predictions,  and  corrective  actions. 
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rdecom^  Evaluating/Managing  FMEAs 


Preparing: 

Ensure  appropriate  contracting  language  is  crafted  and  understood  by 
parties  involved 

Construct  internal  reference  documents  as  appropriate 

•  P-Diagram 

•  Functional  Diagram 

•  WBS 

•  Etc 

Determine  the  “key  subsystems”  for  which  FMEA  has  to  be  delivered  to  the 
Government  for  review,  and  are  documented  in  the  contract. 

•  The  contractors  are  required  to  complete  FMEA  on  all  systems,  and 
they  should  be  visible  to  the  Government. 

•  Key  subsystems  are  determined  using  lessons  learned  in  the  TD 
phase  or  using  engineering  judgment. 

Assemble  appropriate  cross-functional  teams 

•  Depending  on  area  of  DFMEAor  PFMEA  being  reviewed,  the  teams 
will  include  different  sets  of  participants 
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rdecom^  Evaluating/Managing  FMEAs 


Evaluating: 

Cross-check  reference  documents  against  internal  documents  for 
concurrence 

Use  the  checklists  in  the  appendix  of  this  material  to  ensure  content 
and  quality  of  FMEAs 

Identify  gaps 

•  Establish  action  item  lists  detailing  activities  necessary  to 
improve  quality  and/or  content  of  FMEA 

•  Ensure  appropriate  participants  are  notified  of  action  items  via 
appropriate  contracting  channels 

•  Confirm  that  the  design-in  process  parameters  meet  user 
requirements  if  specifically  spelled  out  as  a  requirement. 
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rdecom^  Evaluating/Managing  FMEAs 


Managing: 

Work  with  FMEA  owners  to  address  and  close  identified  action  items 

Ensure  FMEAs  are  reviewed  at  appropriate  times  throughout  contract 
execution 

•  Technical  Reviews 

•  Appropriate  IPT  Meetings 

Ensure  FMEAs  are  treated  as  living  documents  and  updated 
throughout  the  lifecycle  of  the  product 

•  Feedback  from  reviews 

•  Risk  mitigation  activities 

•  Root  cause  analysis/lssue  resolution 

•  Whenever  a  change  is  made  to  the  system 
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RDECOM 


Quick  FMEA  Review  Technique 


_  S^EtSPil 

_  C&mponeit: 


Vehicle 
Pov^rtrai  n 

Engine  Block /Tran emission  Case 


Potential 

Failure  Mode  and  Effects  Analysis 

(Hfesigi  /Process  FMEA) 


Model  Yei  /Yetikte^ :  AJI 

CcfETes"i:  FMEATeam  Members  -  Design  Engineer,  Manufacturing  Engineer,  Reliability  Engineer,  Program  Manager, Ch 


Item  /  Function 


Item  Name  /  Dsign 
Intent 


Potential  Failu  re 
Mode 


Manner  in  whidi 
inten  ded  Function 
Fait  in  Technical 
Terms 


Potential  Effects  of 
Failuie 


Effeds  of  Failire  Mode  on 
Fu  nctic  n  th  at  C  ustcmer  may 
Notice  or  Experience 


Potential  Causes  / 
Mechanisms  of  Failure 


Mechanism  that  causes  the 
Failue  Mode 


Current 
Desig  n 
Controls 
Prevention 


Current 
Desig  n 
Controls 
Detection 


3)  Look  for 
“real”  actions 
and  individuals 
for  the  highest 
RPN’s 


3G 


5)  Ensure 
Actions  are 
being  tracked 


pon  ability 
i  T arget 
ip  let  ion 
Date 


Actions  to 
and  mitigate 


Action  sTak 


Action 
Description^ 
Dde 


/V 


1)  Start  with 
understanding 
the  function. 
Make  sure  the 
team  really 
understands 
what  it  is  really 
supposed  to 
do. 


4)  Look  for 
highest 
Severity, 
Occurrence,  & 
Detection  #’s. 
Cross  check 
with  rating 
charts 


L 


2)  Look  for 
the  highest 
RPN  numbers 


6)  Repeat 
until  you  have 
tracked  down 
to  lower  RPN 
#’s 
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Section  E 


Summary  and  Appendix 
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RDEcmwy  Summary  of  all  FMEA  Activities 


FMEA  Process  Workflow 


^  Start  ^ 


Mgmt 


Identify  program1' 
project  fax  FMEA 


Mg  ml 

Allocate  resources 
to  conduct 
FMEA(s) 


FMEA  Team 


FMEA  Team 


FMEA  Team 


FMEA  Admin 


Create  FMEA 
development  plan  to 
Include  type  of  FMEAs  &. 
assign  roles  & 
responsibilities 


Gather  product/ 
process 
specifications, 
quality 

requirements,  etc 


Assign  FMEA  tool 
administrator 


Create  and 
maintain  project 
folder  in  FMEA 
database  and 
enter  FMEA/s) 


*0 


FMEA  Lead 


~u  tfn 

5  S1 

E  £ 


Transfer  failure 
mode  to  risfc, 
issue,  no  action 


■  ■'  ©  0 

© 


©  0 


TECHNOLOGY  DRIVEN.  WARFIGHTER  FOCUSED. 


Unclassified 


95 


DFMEA  Severity  Table 


2— 


Category  (Product) 

Severity  of  Effect  on  Product  (DFMEA) 

FMEA 

Rank 

Risk 

Conseq¬ 

uence 

Rank 

Safety  and/or  Regulatory 
Compliance 

Failure  could  injure  the  user  or  an  employee 

10 

5 

Failure  would  create  noncompliance  with  federal  regulations 

9 

Primary  Function  (Essential) 

Failure  renders  the  unit  inoperable  or  unfit  for  use 

8 

Failure  causes  a  high  degree  of  user  dissatisfaction 

7 

4 

Secondary  Function  (Convenient) 

Failure  results  in  a  subsystem  or  partial  malfunction  of  the 

product 

6 

Failure  creates  enough  of  a  performance  loss  to  cause  the  user 

to  complain 

5 

3 

Annoyance 

Failure  can  be  overcome  with  modifications  to  the  user's 
process  or  product,  but  there  is  minor  performance  loss 

4 

Failure  would  create  a  minor  nuisance  to  the  user,  but  the  user 
can  overcome  it  without  performance  loss 

3 

2 

Failure  may  not  be  readily  apparent  to  the  user,  but  would  have 
minor  effects  on  the  user's  process  or  product 

2 

No  Effect 

Failure  would  not  be  noticeable  to  the  user  and  would  not 

affect  the  user's  process  or  product 

1 

1 
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DFMEA  Occurrence  Table 


Likelihood  of  Failure 

Occurrence  of  Cause  (DFMEA) 

FMEA 

Rank 

Risk  Likelih¬ 
ood  Rank 

Very  High 

New  technology/new  design  with  no  history 

10 

5 

High 

Failure  is  inevitable  with  new  design,  new  application,  or  change  in 
duty  cycle/operating  conditions 

9 

Failure  is  likely  with  new  design,  new  application,  or  change  in  duty 
cycle/operating  conditions 

8 

4 

Failure  is  uncertain  with  new  design,  new  application,  or  change  in 
duty  cycle/operating  conditions 

7 

Moderate 

Frequent  failures  associated  with  similar  designs  or  in  design 
simulation  and  testing 

6 

3 

Occasional  failures  associated  with  similar  designs  or  in  design 
simulation  and  testing 

5 

Isolated  failures  associated  with  similar  design  or  in  design 
simulation  and  testing 

4 

2 

Low 

Only  isolated  failures  associate  with  almost  identical  design  or  in 
design  simulation  and  testing 

3 

No  observed  failures  associated  with  almost  identical  design  or  in 
design  simulation  and  testing 

2 

1 

Very  Low 

Failure  is  eliminated  through  preventative  control 

1 
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DFMEA  Detection  Table 


Category  (Product) 

Detection  of  Cause  (DFMEA) 

FMEA 

Rank 

Absolute 

Uncertainty 

No  current  design  control;  cannot  detect  or  is  not  analyzed 

10 

Difficult  to  Detect 

Design  analysis/detection  controls  have  a  weak  detection  capability;  virtual  analysis  (e.g.  CAE,  FEA,  etc.)  is 

not  correlated  to  expected  actual  operating  conditions 

9 

Post  Design  Freeze 

and  Prior  to  Launch 

Product  verification/validation  after  design  freeze  and  prior  to  launch  with  pass/fail  testing  (sub-system 
or  system  testing  with  acceptance  criteria  e.g.  ride  and  handling,  shipping  evaluation,  etc.) 

8 

Product  verification/validation  after  design  freeze  and  prior  to  launch  with  test  to  failure  testing  (sub- 
system  or  system  testing  until  failure  occurs,  testing  of  system  interactions,  etc.) 

7 

Product  verification/validation  after  design  freeze  and  prior  to  launch  with  degradation  testing  (sub- 
system  or  system  testing  after  durability  test  e.g.  function  check) 

6 

Prior  to  Design 

Freeze 

Product  validation  (reliability  testing,  development  or  validation  tests)  prior  to  design  freeze  using 
pass/fail  testing  (e.g.  acceptance  criteria  for  performance,  function  checks,  etc.) 

5 

Product  validation  (reliability  testing,  development  or  validation  tests)  prior  to  design  freeze  using  test  to 

failure  (e.g.  until  leaks,  yields,  cracks,  etc.) 

4 

Product  validation  (reliability  testing,  development  or  validation  tests)  prior  to  design  freeze  using 
degradation  testing  (e.g.  data  trends,  before/after  values,  etc.) 

3 

Virtual  Analysis  - 

Correlated 

Design  analysis/detection  controls  have  a  strong  detection  capability.  Virtual  analysis  (e.g.  CAE,  FEA,  etc.) 
is  highly  correlated  with  actual  and/or  expected  operating  conditions  prior  to  design  freeze 

2 

Detection  not 

applicable;  Failure 

Prevention 

Failure  cause  or  failure  mode  cannot  occur  because  it  is  fully  prevented  through  design  solutions  (e.g. 
proven  design  standard/best  practice  or  common  material,  etc.) 

1 
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PFMEA  Severity  Table 


2— 


Category (Process) 

Severity  of  Effect  on  Process  (PFMEA) 

FMEA 

Rank 

Risk 

Conseq¬ 

uence 

Rank 

Safety  and/or  Regulatory 
Compliance 

May  endanger  operator  (machine  or  assembly)  without  warning 

10 

5 

May  endanger  operator  (machine  or  assembly)  with  warning 

9 

Major  Disruption;  Major  Effect 
on  Throughput 

100%  of  product  may  have  to  be  scrapped  and/or  line  shutdown  or  stop  ship 

8 

4 

Significant  Disruption; 
Significant  Effect  on 
Throughput 

A  portion  of  the  production  run  may  have  to  be  scrapped,  and/or  deviation  from 
primary  process,  and/or  decreased  line  speed  or  added  manpower 

7 

Rework  out-of-station; 

Moderate  Effect  on 

Throughput 

100%  of  production  run  may  have  to  be  reworked  off  line  and  accepted 

6 

3 

A  portion  of  the  production  run  may  have  to  be  reworked  off  line  and  accepted 

5 

Rework  in-station;  Minor 
Effect  on  Throughput 

100%  of  production  run  may  have  to  be  reworked  in  station  before  it  is  processed 

4 

2 

A  portion  of  the  production  run  may  have  to  be  reworked  in  station  before  it  is 

processed 

3 

Minor  Disruption 

Slight  inconvenience  to  process,  operation,  or  operator 

2 

1 

No  Effect 

No  discernable  effect 

1 
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PFMEA  Occurrence  Table 


Likelihood  of 

Failure 

Occurrence  of  Cause  (PFMEA) 

Ppk 

FMEA 

Rank 

Risk 

Likelihood 

Rank 

Very  High 

>  100  per  thousand  pieces 

<0.55 

10 

5 

High 

50  per  thousand  pieces 

>0.55 

9 

20  per  thousand  pieces 

>0.78 

8 

4 

10  per  thousand  pieces 

>0.86 

7 

Moderate 

5  per  thousand  pieces 

>0.94 

6 

3 

2  per  thousand  pieces 

>1.00 

5 

1  per  thousand  pieces 

>1.10 

4 

2 

Low 

0.5  per  thousand  pieces 

>1.20 

3 

0.1  per  thousand  pieces 

>1.30 

2 

1 

Very  Low 

<0.01  per  thousand  pieces 

>1.67 

1 

Note:  The  Ppk  values  are  to  be  used  by  the  FMEA  team  as  guidance  to  assist  in  determining  an  occurrence 
ranking  when  valid  statistical  data  is  available.  No  other  use  of  the  Ppk  values  is  intended 
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Category  (Process) 

Detection  of  Cause  (PFMEA) 

FMEA  Rank 

Absolute  Uncertainty 

No  current  process  control;  cannot  detect  or  is  not  analyzed 

10 

Difficult  to  Detect 

Defect  (failure  mode)  and/or  error  (cause)  is  not  easily  detected  (e.g.  random  audits) 

9 

Defect  Detection 

Post  Processing 

Defect  (failure  mode)  detection  post-processing  by  operator  through 
visual/tactile/audible  means 

8 

Defect  Detection  at 

Source 

Defect  (failure  mode)  detection  in-station  by  operator  through  visual/tactile/audible 
means  or  post-processing  through  use  of  attribute  gauging  (go/no-go,  manual 
torque  check/clicker  wrench,  etc.) 

7 

Defect  Detection 

Post  Processing 

Defect  (failure  mode)  detection  post-processing  by  operator  through  use  of  variable 
gauging  or  in-station  by  operator  through  use  of  attribute  gauging  (go/no-go, 
manual  torque  check/clicker  wrench,  etc.) 

6 

Defect  Detection  at 

Source 

Defect  (failure  mode)  or  error  (cause)  detection  in-station  by  operator  through  use 
of  variable  gauging  or  by  automated  controls  in-station  that  will  detect  discrepant 
part  and  notify  operator  (light,  buzzer,  etc.);  gauging  performed  on  setup  and  first- 

piece  check  (for  setup  causes  only) 

5 

Defect  Detection 

Post  Processing 

Defect  (failure  mode)  detection  post-processing  by  automated  controls  that  will 
detect  discrepant  part  and  lock  part  to  prevent  further  processing 

4 

Defect  Detection  at 

Source 

Defect  (failure  mode)  detection  in-station  by  automated  controls  that  will  detect 
discrepant  part  and  automatically  lock  part  in  station  to  prevent  further  processing 

3 

Error  Detection 

and/or  Defect 

Prevention 

Error  (cause)  detection  in-station  by  automated  controls  that  will  detect  error  and 
prevent  discrepant  part  from  being  made 

2 

Detection  not 

applicable;  Error 

Prevention 

Error  (cause)  prevention  as  a  result  of  fixture  design,  machine  design  or  part  design 

1 
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Potential  — ,  fmea#: 

Failure  Mode  and  Effects  Analysis  (  i  Jcontract#: 

_  System 

V  ./ _  Subsystems 

(Design  FMEA) 

Supplier : 

Component: 

Desian  Responsibility:  f  *  ]  Prepared  by: 

Gove  rn  me  nt  POC :  ^ ^ 

V  /  Proqram  name  :  ^ — -v 

0) 

FMEA  key  date:  f  t  J  FMEA  date  (Oria.) :  Revision  date : 

\J  )  Core  Team  :  ^ — V 

Item  # 

Item  name  / 
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Potential  Failure 

Mode 
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Item  # 

Name 

Description 

Further  comments 

1 

FMEA  Number 

Contract  # 

Supplier/DPRP 

Enter  an  appropriate  FMEA  document  number,  which  may  be  used  for 
tracking.  Fill  in  as  many  fields  as  information  allows. 

FMEA  numbers  should  follow  a  sequence  as 
dictated  by  the  existing  reccomendations  or 
practices  of  the  OEM,  Vendor,  Supplier, 
Department  and/or  Group  who  has  design 
responsibility. 

2 

System,  Subsystem,  or  Component 

Check  or  mark  the  appropriate  level  of  analysis  and  enterthe  name  of 
the  system,  subsystem  or  component  being  analyzed. 

-  A  System  is  a  set  of  interacting  or 
interdependent  components  forming  an 
integrated  whole.  A  vehicle  is  an  example  of 

a  system. 

-  A  Sub-System  is  a  set  of  elements,  which  is  a 
system  itself,  and  a  component  of  a  larger 
system.  The  HVAC  in  a  vehicle  is  an  example 
of  a  sub-system. 

-  A  component  is  an  element  which,  in 
conjunction  with  other  components,  come 
together  in  an  integrated  fashion  to  create  a 
sub-system  or  system.  The  compressor  in  a 
HVAC  sub-system  is  an  example  of  a 
component. 

Components  are  themselves  made  up  of  any 
number  of  elements,  and/or  sub¬ 
components,  but  refrain  from  this  as  a 
justification  to  label  certain  components  as 
sub-systems. 

3  Design  responsibility  Enter  the  OEM,  Vendor,  Supplier,  Department,  and/or  Group  who  is 

responsible  forthe  design  of  the  System,  Subsystem,  or  Component 
described  in  item  2.  Enter  the  name  and  contact  information  forthe 
Government  Point  of  Contact. 
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4 

Prepared  by 

Enterthe  name.,  telephone  number,  e-mail  address,  (and  company 
name  where  applicable)  of  the  POC  responsible  for  preparingthe  FMEA. 

Use  best  judgement  as  to  how  much 
information  is  needed.  Non-Government 

FMEA  forms  should  specify  company  names 
while  Government  FMEA  forms  may  contain 
branch  orgroup  names.  In  most  cases  the 

FMEA  is  prepared  by  a  member  of  the  group 
holding  Design  Responsibility,  but  there  may 
be  exceptions.  In  all  cases  provide  enough 

information  for  the  readerto  understand  the 

origination  point  of  the  FMEA. 

5 

Program  name 

Enterthe  name  of  the  program. 

6 

FMEA  Key  date 

Enterthe  date  the  design  FMEA  is  to  be  completed  by  and  specify  its 
relevance. 

FMEA  is  a  proactive  tool  meant  to  be  a 
"before  the  event"  action,  not  an  "aftterthe 

fact"  exercise.  Therefore  the  FMEA  should  be 

completed  BEFORE  significant  events  so  that 
actions  can  be  taken  to  mitigate  risk  BEFORE 
failure  happens.  Examples  of  relevant  dates 
might  be  Full  or  Low  Rate  Production  (  FRP  or 
LRP),  Milestones,  Design  Reviews,  etc. 

7 

FMEA  date(Orig)  and  Revision  date 

Enterthe  date  the  original  FMEA  was  compiled  and  date  of  the  latest 

revision. 

Since  the  FMEA  is  a  living  document:  it  is 
important  to  update  the  revision  date  ANY 
time  changes  are  made  to  the  FMEA. 
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The  core  team  is  also  the  group  of  individuals 
who,  along  with  the  person  indicated  in  Item 
4  as  the  person  responsible  forthe 
preparation,  will  create  the  FMEA  before  the 
key  date.  It  is  strongly  recommended  that 
complete  contact  information  be  maintained 
either  on  the  FMEA  in  this  field ,  as  an 
attachment  to  the  form,  or  as  a  separate  tab  in 
the  excel  file.  The  life  of  an  FMEA  can 
sometimes  outlast  that  of  phone  numbers, 
addresses,  and  current  employees.  Therefore 
all  attempts  to  be  current  and  complete  are 
helpful  if  original  team  members  need  to  be 
contacted.  Updating  contact:  information  is  a 
legitimate  revision  reason  and  the  date  of 
such  an  action  should  be  recorded  in  Item  7. 
Core  team  members  should  be  labelled  with 
the  following  identifiers:  (G)  Government,  (O) 
OEM  or  Prime,  (SC)  service  contractor. 


9 

Item  # 

Enterthe  number  of  the  item  as  it  appears  on  the  WBS  or  any  other 
document  which  describes  the  breakdown  of  the  system,  sub-system,  or 
component  in  question. 

This  field  is  useful  to  tie  the  FMEA  back  to  it's 
support  documents.  An  example  might  look 

like  1.1.2. 3  or  similar  format  fora  WBS 

element. 

10 

Item  name/Function 

Enterthe  name  of  the  item  being  analyzed.  Use  the  nomenclature  and 
show  the  design  level  as  indicated  on  the  engineering  drawing.  Below 
the  name,  enterthe  function  of  the  item.  Be  concise  but  limit  the 
description  to  verb/noun  phrases  when  possible.  If  the  item  has 
multiple  functions  list  each  as  a  separate  function  as  they  may  have 
their  own  unique  failure  modes  and  effects. 

When  describing  functions  keep  in  mind  that 
the  way  they  are  worded  can  sometimes 
make  it  easierto  describe  how  they  can  fail. 
Functions  like  "transmit  data"  or  "support 
load"  are  easy  to  turn  around  into  potential 
failure  descriptions. 

Core  team 


List  the  names  of  the  responsible  individuals  and  departments  which 
have  the  authority  to  identify  and  or  perform  tasks. 
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11  Potential  Failure  Mode 


12  Potential  Effect(s)  of  Failure 


Potential  Failure  Mode  is  defined  as  the  manner  in  which  a  component, 
subsystem,  or  system  could  potentially  fail  to  meet  its  intended 
function.  The  most  obvious  potential  failure  mode  is  the  opposite  of 
the  intended  function.  Enter  a  short  description  that  characterizes  the 
failure. 


Rememberthat  although  the  opposite  of  the 
intended  function  is  one  obvious  failure 
mode  it  may  not  be  the  only  failure  mode.  All 
of  the  potential  failure  modes  should  be 
listed,  but  the  FMEAteam  should  be  careful 
not  to  identify  multiple  failure  modes  unless 
they  are  sure  of  their  uniquness.  For 
instance,  if  the  function  is  "inject  fuel"  the 
team  may  have  to  consider  whetherthe 
potential  failures  "no  fuel  injected"  and  "too 
little  fuel  injected"  are  really  unique  and  have 
different  consequences  and  solutions,  or  if 
they  are  just  two  levels  of  the  same  failure 
mode.  Do  not  forget  the  less  obvious  failures 
such  as  "fit"  [describing  tolerance  stack  ups), 
"interface"  (a  sub-set  of  fit  meaningthat  this 
item  must  mate  with  another  item),  and 
"form"  (the  ability  to  maintain  shape). 


Enterthe  Potential  Effect  of  Failure  in  terms  of  what  the  customer  might  The  effect  of  the  failure  mode  is  described  by 
notice  or  experience,  remembering  that  the  customer  may  be  an  envisioning  the  effect  it  will  have  on  the  user, 

internal  customer  or  the  ultimate  end  user.  Typical  descriptions  of  design  failure  effects 

are  "rough  operation",  "excessive  noise", 
"intermittent  operation",  etc. 
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13 


Potential  Causes  /  Mechanisms  of  Enterthe  Potential  Cause  or  Mechanism  of  the  failure.  Potential  cause  Potential  causes  are  often  requirements  or 

Failure  of  Failure  is  defined  as  how  the  failure  could  occur,  described  in  terms  specifications  that  have  not  been  met  in  the 

of  somethingthat  can  be  corrected  or  can  be  controlled.  execution  of  the  function.  This  field  should 

contain  phrases  that  accurately  describe  the 
reason  forthe  failure  to  happen.  These 
descriptions  usualy  include  words  like 
"incorrect"  or  "insufficient"  or  "excessive" 


followed  by  some  noun.  Examples:  "incorrect 
gap",  "insufficient  lubrication",  "excessive 
heat".  Choosingto  describe  causes  in  this 
fashion  makes  identifying  their  solutions 
straight  forward.  Potential  causes  should  be 
"root"  causes  and  may  require  problem 
solvingto  discover. 

14  Current  Design  Controls  -  Prevention  List  the  controls/feature  that  prevent  the  cause  (and  in  turn  the  failure  Prevention  controls  are  preferable  over 

mode)  from  occuring,  or  reduce  its  rate  of  occurrence.  detection  controls  as  they  actually  PREVENT 

the  cause  from  happening.  This  type  of 
control  suggests  that  the  cause  (item  13) 
cannot  happen  because  it  is  not  possible. 

Error  proofing  is  often  considered  a  form  of 
prevention.  For  example,  the  spout  of  a 
diesel  fuel  dispenser  is  designed  to  be  too 
large  to  fit  into  the  gas  tank  opening  of  a 
conventional  "gas"  vehicle,  thereby  greatly 
reducing  the  potential  failure  of  engine 
damage.  Note  the  distinction  of  where  to 
place  control;  by  controllingthe  ROOT  CAUSES 
failures  are  avoided.  Failure  modes  are  not 
controlled  -  their  causes  are  controlled. 
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15  Current  Design  Controls  -  Detection  List  the  controls/feature  that  allow  the  cause  orthe  failure  mode  to  be  Detection  controls  are  different  from 

detected  as  early  as  possible,  preferably  before  effecting  function.  prevention  controls  in  that  they  do  not 

control  the  cause,  but  instead  give  warning  as 
to  its  presence.  Sometimes  causes  cannot  be 
prevented  and  the  alternative  is  to  simply  be 
aware  of  them  before  they  can  generate  a 
failure.  Regular  inspections  or  preventative 
maintenance  can  "find”  causes  before  they 
can  result  in  failure.  Statistical  process 
control  (SPCJ,  training,  and  written 
procedures  are  also  means  of  raising 
awareness  and  making  causes  more 
detectable.  Sometimes  causes  cannot  be 
prevented  and  detection  is  the  highest  level 
of  control  available. 

16  Severity(S)  and  Classification  Severity  is  an  assessment  or  ranking  of  the  seriousness  of  the  effect  Do  not  confuse  failure  mode  with  effect. 

(item  12)  of  the  potential  failure  mode  to  the  next  component.  Rank  the  effect,  not:  the  failure  mode.  Some 

subsystem,  system  or  customer  if  it  occurs.  Severity  applies  to  the  effect  failure  modes  have  very  severe  effects  while 
only.  others  are  negligble. 

Classification  refers  to  any  special  characteristics  of  the  design  or  high 
priority  failure  modes.  Key  requirements  or  important  product 
characteristics  can  be  noted  here  (i.e.  KPP,  KCC,  KPC,  KSA,  etc}.  Entering 
something  in  the  classification  column  indicates  that  the  effect  of  this 
failure  mode  requires  mitigation  action  regardless  of  its  associated 
Occurrence  and  Detection  ratings.  In  addition.  Safety  and  Regulatory 
classifications  imply  higher  severity  ratings  [i.e.  3  or  10}  and  similarly 
demand  mitigation  action.  When  entering  a  classification  use  or 
recognize  the  accepted  abbreviations  or  symbols  which  may  be 
company  or  industry  specific  (note:  Safety  is  popularly  classified  with  an 
5,  Regulatory  with  and  R).  Remember  that  entering  any  classification  at 
all  means  mitigation  action  needs  to  be  taken. 
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17 

Occurrence  (0} 

Occurrence  is  an  assessment  of  the  likelihood  that  a  specific 
cause/mechanism  (item  13)  will  occur  or  present  itself.  The  likelihood  of 
occurrence  ranking  number  has  a  meaning  ratherthan  a  value. 

Removing  or  controlling  one  or  more  of  the  causes/mechanisms  of  the 
failure  mode  through  a  design  change  is  the  only  way  a  reduction  in  the 
occurrence  ranking  can  be  affected. 

Do  not  confuse  failure  mode  with  occurrence 

of  cause.  Rank  the  possibility  of  the  cause 
happening,  not  the  possibility  of  the  failure 
mode  happening. 

IS 

Detection(D) 

Detection  is  an  assessment  of  the  likelihood  that  the  Current  Controls 
(items  14  &  15)  will  detect  the  Cause  of  the  failure  mode,  thereby 
preventing  it,  orthat  the  subsequent  failure  mode  will  be  detected 
before  it  reaches  the  customer. 

19 

RPN 

The  Risk  Priority  Number  is  the  product  of  the  Severity  (S),  Occurrence 
(O),  and  Detection  (D)  ranking.  RPN=(S)  x  (0)  x  (D). 

For  higher  RPNs  the  team  must  undertake 
efforts  to  reduce  this  calculated  risk  through 
mitigative  action.  It  is  the  team's  discretion  as 
to  what  constitutes  "high"  RPN  and  what 
deserves  action  to  be  taken. 

20' 

Recommended  Actions 

When  the  failure  modes  have  been  rank  ordered  by  RPN,  mitigative 
action  should  be  first  directed  at  the  highest  ranked  concerns  and  critical 
items.  The  intent  of  any  recommended  action  is  to  reduce  any  or  all  of 
the  occurrence,  serverity,  and  or  detection  rankings.  After  using  RPN  as 
an  indicator  of  mitigation  action,  next  look  for  any  failure  mode  that  had 
something  entered  into  the  Classification  column.  Create  mitigation 
actions  for  any  failure  mode  which  has  a  classification,  no  matter  what 
the  classification  is. 

Risks  identified  by  FMEA  that  warrant  action 
should  be  managed  through  the  Risk  Recon 
tool. 

21 

Responsibility  St  Target  Completion 

Date 

Enterthe  organization  and  individual  responsible  for  the  recommended 
action  and  the  target  completion  date. 

Risks  identified  by  FMEA  that  warrant  action 
should  be  managed  through  the  Risk  Recon 

tool. 

22 

Actions  Taken 

After  an  action  has  been  implemented,  enter  a  brief  description  of  the 
actual  action  and  effective  date. 

Risks  identified  by  FMEA  that  warrant  action 
should  be  managed  through  the  Risk  Recon 
tool. 

23 

Action  Results 

After  action  has  been  completed,  re-assess  and  record  the  new 
severity,  occurrence,  and  detection  rankings.  Calculate  and  record  the 
resulting  RPN.  If  no  actions  are  taken,  leave  the  "Action  Results"  and 
related  ranking  columns  blank. 

Risks  identified  by  FMEA  that  warrant  action 
should  be  managed  through  the  Risk  Recon 
tool. 
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Potential  ^  fmea#: 

Failure  Mode  and  Effects  Analysis  f  \  J  Contract#: 
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V  J _  Subsystems 

(Process  FMEA) 
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Item  # 

Name 

Description 

Further  comments 

1 

FMEA  Number 

Contract  # 

Supplier/DPRP 

Enter  an  appropriate  FMEA  document  number,  which  may  be  used  for 
tracking.  Fill  in  as  many  fields  as  information  allows. 

FMEA  numbers  should  follow  a  sequence  as 
dictated  by  the  existing  reccomendations  or 
practices  of  the  OEM,  Vendor,  Supplier, 
Department  and/or  Group  who  has  design 
responsibility. 

2 

System,  Subsystem,  or  Component 

Check  or  mark  the  appropriate  level  of  analysis  and  enterthe  name  of 
the  system,  subsystem  or  component  being  analyzed. 

-  A  System  is  a  set  of  interacting  or 
interdependent  components  forming  an 
integrated  whole.  A  vehicle  is  an  example  of 

a  system.  Business  ortransactional  processes 
may  be  considered  systems,  but  there  is  no 
further  breakdown  into  sub-systems  or 
components. 

-  A  Sub-System  is  a  set  of  elements,  which  is  a 
system  itself,  and  a  component  of  a  larger 
system.  The  HVAC  in  a  vehicle  Ls  an  example 
of  a  sub-system. 

-A  component  is  an  element  which,  in 
conjunction  with  other  components,  come 
together  in  an  integrated  fashion  to  create  a 
sub-system  or  system.  The  compressor  in  a 
HVAC  sub-system  is  an  example  of  a 
component. 

Components  are  themselves  made  up  of  any 
number  of  elements,  and/or  sub¬ 
components,  but  refrain  from  this  as  a 
justification  to  label  certain  components  as 
sub-systems. 

3  Process  responsibility  Enter  the  OEM,  Vendor,  Supplier,  Department,  and/or  Group  who  is 

responsible  forthe  process  described  in  item  2.  Enterthe  name  and 
contact  information  forthe  Government  Point  of  Contact. 
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4 

Prepared  by 

Enterthe  name,  telephone  number,  e-mail  address,  (and  company 
name  where  applicable)  of  the  POC  responsible  for  preparingthe  FMEA. 

Use  best  judgement  as  to  how  much 
information  is  needed.  Non-Government 
FMEA  forms  should  specify  company  names 
while  Government  FMEA  forms  may  contain 
branch  orgroup  names.  In  most  cases  the 

FMEA  is  prepared  by  a  member  of  the  group 
holding  Design  Responsibility,  but  there  may 
be  exceptions.  In  all  cases  provide  enough 
information  forthe  readerto  understand  the 
origination  point  of  the  FMEA. 

5 

Program  name 

Enterthe  name  of  the  program/process. 

6 

FMEA  Key  date 

Enterthe  date  the  process  FMEA  is  to  be  completed  by  and  specify  its 
relevance. 

FMEA  is  a  proactive  tool  meant  to  be  a 
"before  the  event"  action,  not  an  "after  the 

fact"  exercise.  Therefore  the  FMEA  should  be 
completed  BEFORE  significant  events  so  that 
actions  can  be  taken  to  mitigate  risk  BEFORE 
failure  happens.  Examples  of  relevant  dates 
might  be  Full  or  Low  Rate  Production  (FRP  or 
LRP),  Milestones,  Design  Reviews,  etc. 

7 

FMEA  date(Orig)  and  Revision  date 

Enterthe  date  the  original  FMEA  was  compiled  and  date  of  the  latest 

revision. 

Since  the  FMEA  is  a  living  document  it  is 
important  to  update  the  revision  date  ANY 
time  changes  are  made  to  the  FMEA. 
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10 


Core  team  List  the  names  of  the  responsible  individuals  and  departments  which  The  core  team  is  also  the  group  of  individuals 

have  the  authority  to  identify  and  or  perform  tasks.  who.,  along  with  the  person  indicated  in  Item 

4  as  the  person  responsible  forthe 
preparation,  will  create  the  FMEA  before  the 
key  date.  It  is  strongly  recommended  that 
complete  contact  information  be  maintained 
either  on  the  FMEA  in  this  field ,  as  an 
attachment  to  the  form,  or  as  a  separate  tab  in 
the  excel  file.  The  life  of  an  FMEA  can 
sometimes  outlast  that  of  phone  numbers, 
addresses,  and  current  employees.  Therefore 
all  attempts  to  be  current  and  complete  are 
helpful  if  original  team  members  need  to  be 
contacted.  Updating  contact  information  is  a 
legitimate  revision  reason  and  the  date  of 
such  an  action  should  be  recorded  in  Item  7. 
Core  team  members  should  be  labelled  with 
the  following  identifiers:  (G)  Government,  [□) 
OEM  or  Prime,  (SC)  service  contractor. 


Process  step  # 


Process  step  function  /  requirements 


Enterthe  number  of  the  item  as  it  appears  on  the  Process  Map,  Process 
Flow  Diagram,  or  any  other  document  which  describes  the  flow  and  the 
order  of  the  process. 

Enter  a  simple  description  of  the  process  or  operation  being  analyzed 
which  indicates  the  purpose  of  the  process  or  operation.  If  the  process 
or  operation  has  multiple  steps  list  each  separately  as  they  may  have 
their  own  unique  failure  modes  and  effects. 


This  field  is  useful  to  fie  the  FMEA  back  to  it's 
support  documents.  An  example  might  be 
STEP  1  for  a  Process  Map  block. 

When  describing  process  steps  keep  in  mind 
that  the  way  they  are  worded  can  sometimes 
make  it  easierto  describe  how  they  can  fail. 
Use  verb  noun  phrases.  Descriptions  like 
"drill  hole"  or  "solder  wire  to  contact"  are 
easy  to  turn  around  into  potential  failure 
descriptions.  For  business  and  transactional 
processes  examples  are  "perform  design 
review"  or  "create  master  schedule". 
Depending  on  the  source  of  the  information  it 
may  be  appropriate  to  enter  requirements  in 
the  form  of  measureable  metrics  orto  refer 
backto  the  source  while  creating  the  FMEA. 
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11  Potential  Failure  Mode 


12  Potential  Effedt(s)  of  Failure 


Potential  Failure  Mode  is  defined  as  the  manner  in  which  the  process 
could  potentially  fail  to  meet  the  process  requirements  and/or  design 
intent  as  described  in  the  Process  Step  Function  /  Requirements  column 
(item  10).  The  most  obvious  potential  failure  mode  is  the  opposite  of 
the  intended  output.  Enter  a  short  description  that  characterizes  the 
failure. 


Enter  the  Potential  Effect  of  Failure  in  terms  of  what  the  customer  might 
notice  or  experience,  remembering  that  the  customer  may  be  an 
internal  customer,  the  ultimate  end  user,  or  even  the  next  process  step. 


Remember  that  although  the  opposite  of  the 
intended  output  is  one  obvious  failure  mode 
it  may  not  be  the  only  failure  mode.  Be  sure 
to  consider  failure  modes  that  can  result 
when  process  settings  are  incorrect  such  as 
"bent11,  "cracked",  "burred",  "short  ci routed", 
"open  circuited",  etc.  All  of  the  potential 
failure  modes  should  be  listed,  but  the  FMEA 
team  should  be  careful  not  to  identify 
multiple  failure  modes  unless  they  are  sure  of 
their  uniquness.  For  instance,  if  the  function 
is  "drill  hole"  the  team  may  have  to  consider 
whetherthe  potential  failures  "hole  too 
small"  and  "hole  too  large"  are  really  unique 
and  have  different  consequences  and 
solutions,  or  if  they  are  just  two  levels  of  the 
same  failure  mode.  Do  not  forget  the  less 
obvious  failures  such  as  "fit"  (describing 
tolerance  stack  ups),  "interface"  (a  sub-set  of 
fit  meaning  that  this  item  must  mate  with 
another  item},  and  "form"  (the  ability  to 
maintain  shape).  Examples  of  failure  modes 
in  business  and  transactional  processes  are 
"approval  not  received"  or  "invoice  is  paid 
late". 

The  effect  of  the  failure  mode  is  described  by 
envisioning  the  effect  it  will  have  on  the  user 
orthe  next  operation.  Typical  descriptions 
of  process  failure  effects  are  "unit  leaks", 
"high  effort",  "part  will  be  scrapped",  etc. 
Typical  descriptions  that  affect  downstream 
operation  are  "cannot  fasten",  "will  not  fit", 
"causes  excessive  tool  wear",  "will  prompt 
PLC  error  codes",  etc. 
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14 


Potential  causes  are  often  requirements  or 
specifications  that  have  not  been  met  in  the 
execution  of  the  process  or  operation.  This 
field  should  contain  phrases  that  accurately 
describe  the  reason  forthe  failure  to  happen. 
These  descriptions  usualy  include  words  like 
■’incorrect"  or  "insufficient"  or  "excessive" 
followed  by  some  noun.  Examples:  "incorrect 
s  ett  i  ng1  ’,  "ins  uffi  ci  e  nt  welding  cu  rre  nt", 
"excessive  drill  speed".  Other  examples: 
"debris  present",  "worn  tool",  "improper 
setup",  etc.  Choosingto  describe  causes  in 
this  fashion  makes  identifying  their  solutions 
straight  forward.  Potential  causes  should  be 
"root"  causes  and  may  require  problem 
solvingto  discover. 

Current  Process  Controls  -  Prevention  List  the  controls/feature  that  prevent  the  cause  (and  in  turn  the  failure  Prevention  controls  are  preferable  over 

mode)  from  occuring,  or  reduce  its  rate  of  occurrence.  detection  controls  as  they  actually  PREVENT 

the  cause  from  happening.  This  type  of 
control  suggests  that  the  cause  (item  13) 
cannot  happen  because  it  is  not  possible. 

Error  proofing  is  often  considered  a  form  of 
prevention.  For  example,  commonization  of 
fasteners  eliminates  the  possibility  of  using 
the  wrong  fastener  in  any  given  location. 

Note  the  distinction  of  where  to  place 
control;  by  controlling  the  ROOT  CAUSES 
failures  are  avoided.  Failure  modes  are  not 
controlled  -  their  causes  are  controlled. 


Potential  Causes  /  Mechanisms  of  Enterthe  Potential  Cause  or  Mechanism  of  the  failure.  Potential  cause 

Failure  of  Failure  is  defined  as  how  the  failure  could  occur,  described  in  terms 

of  somethingthat  can  be  corrected  or  can  be  controlled. 
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15  Current  Process  Controls  -  Detection  List  the  controls/feature  that  allow  the  cause  or  the  failure  mode  to  be  Detection  controls  are  different  from 

detected  as  early  as  possible,  leading  to  corrective  actions.  prevention  controls  inthatthey  do  not 

control  the  cause,  but  instead  give  warning  as 
to  its  presence.  Sometimes  causes  cannot  be 
prevented  and  the  alternative  is  to  simply  be 
aware  of  them  before  they  can  generate  a 
failure.  Regular  inspections  or  preventative 
maintenance  can  "find"1  causes  before  they 
can  result  in  failure.  Statistical  process 
control  (SPC),  training,  and  written 
procedures  are  also  means  of  raising 
awareness  and  making  causes  more 
detectable.  Sometimes  causes  cannot  be 
prevented  and  detection  is  the  highest  level 
of  control  available. 

16  Severity(S)  and  Classification  Severity  is  an  assessment  or  ranking  of  the  seriousness  of  the  effect  Do  not  confuse  failure  mode  with  effect. 

(item  12)  of  the  potential  failure  mode  to  the  next  component.  Rank  the  effect,  not  the  failure  mode.  Some 

subsystem,  system  or  customer  if  it  occurs.  Severity  applies  to  the  effect  failure  modes  have  very  severe  effects  while 
only.  others  are  negligble. 

Classification  refers  to  any  special  characteristics  of  the  design  or  high 
priority  failure  modes.  Key  requirements  or  important  product 
characteristics  can  be  noted  here  [i.e.  KPP,  KCC,  KPC,  KSA,  etc).  Entering 
something  in  the  classification  column  indicates  that  the  effect  of  this 
failure  mode  requires  mitigation  action  regardless  of  its  associated 
Occurrence  and  Detection  ratings.  In  addition.  Safety  and  Regulatory 
classifications  imply  higher  severity  ratings  (i.e.  3  or  10)  and  similarly 
demand  mitigation  action.  When  entering  a  classification  use  or 
recognize  the  accepted  abbreviations  or  symbols  which  may  be 
company  or  industry  specific  (note:  Safety  is  popularly  classified  with  an 
S,  Regulatory  with  and  R).  Remember  that  entering  any  classification  at 
all  means  mitigation  action  needs  to  be  taken. 

TECHNOLOGY  DRIVEN.  WARFIGHTER  FOCUSED. 
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17 

Occurrence  (0} 

Occurrence  is  an  assessment  of  the  likelihood  that  a  specific 
cause/mechanism  (item  13)  will  occur  or  present  itself.  The  likelihood  of 
occurrence  ranking  number  has  a  meaning  rather  than  a  value. 

Removing  or  controlling  one  or  more  of  the  causes/mechanisms  of  the 
failure  mode  through  a  design  change  is  the  only  way  a  reduction  in  the 
occurrence  ranking  can  be  affected. 

Do  not  confuse  failure  mode  with  occurrence 
of  cause.  Rankthe  possibility  of  the  cause 
happening,  not  the  possibility  of  the  failure 
mode  happening. 

IS 

Detection(D) 

Defection  is  an  assessment  of  the  likelihood  that  the  Current  Controls 
(items  14  &  15)  will  detect  the  cause  of  the  failure  mode,  thereby 
preventing  it,  orthat  the  subsequent  failure  mode  will  be  detected 
before  it  reaches  the  end  user. 

Random  quality  checks  are  not  likely  to  detect 
low  frequency  failure  modes  and  are 
therefore  poor  detection  techniques  relative 
to  statistical  sampling  used  in  SPC  and  control 
charting. 

IS 

RPN 

The  Risk  Priority  Number  is  the  product  of  the  Severity  (S),  Occurrence 
(0),  and  Defection  (D)  ranking.  RPN=(S)  x  (0)  x  (D). 

For  higher  RPNs  the  team  must  undertake 
efforts  to  reduce  this  calculated  risk  through 
corrective  action.  It  is  the  team's  discretion  as 
to  what  constitutes  "high"  RPN  and  what 
deserves  action  to  be  taken. 

20 

Recommended  Actions 

When  the  failure  modes  have  been  rank  ordered  by  RPN,  mitigative 
action  should  be  first  directed  at  the  highest  ranked  concerns  and  critical 
items.  The  intent  of  any  recommended  action  is  to  reduce  any  or  all  of 
the  occurrence,  serverity,  and  or  detection  rankings.  After  using  RPN  as 
an  indicator  of  mitigation  action,  next  look  for  any  failure  mode  that  had 
something  entered  into  the  Classification  column.  Create  mitigation 
actions  for  any  failure  mode  which  has  a  classification,  no  matter  what 
the  classification  is. 

Risks  identified  by  FMEA  that  warrant  action 
should  be  managed  through  the  Risk  Recon 

tool. 

21 

Responsibility  StTarget  Completion 

Date 

Enterfhe  organization  and  individual  responsible  forthe  recommended 
action  and  the  target  completion  date. 

Risks  identified  by  FMEA  that  warrant  action 
should  be  managed  through  the  Risk  Recon 

tool. 

22 

Actions  Taken 

After  an  action  has  been  implemented,  enter  a  brief  description  of  the 
actual  action  and  effective  date. 

Risks  identified  by  FMEA  that  warrant  action 
should  be  managed  through  the  Risk  Recon 

tool. 

23 

Action  Results 

After  action  has  been  completed,  re-assess  and  record  the  new 
severity,  occurrence,  and  detection  rankings.  Calculate  and  record  the 
resulting  RPN.  If  no  actions  are  taken,  leave  the  "Action  Results"  and 
related  ranking  columns  blank. 

Risks  identified  by  FMEA  that  warrant  action 
should  be  managed  through  the  Risk  Recon 

tool. 
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□ 

Design  FMEA  Development  &  Audit  Summary 

Name  o  f  Component,  Sub-System,  System: 

Internal  or  Contractor  (Specify  Contractor): 

Responsible  person  &  date  reviewed  against  this  checklist: 

Accept.  Consistent  Adherence  to  FMEA  Criteria 

Revision  Required. 

|Yes  No  Comments 

1 

Preparation  Steps  for  DFMEA  Lead  and  Team  members: 

la 

Obtain  &  review  DFMEA.  Review  relevant  background  materials,  including:  Engineering 
Specifications.  DFMEAs.  TEMP.  PFMEAs  and  Customer  feedback  to  identify  required 
functions  &  historical  performance  of  predecessor  products. 

lb 

Construct  a  Boundary  or  P-  Diagram  to  define  the  Component  Module  or  System  for  which  the 
DFMEA  is  being  developed. 

1c 

Create  a  Function  Model  (or  equivalent}  for  the  component,  module  or  system. 

2 

Header  Information:  Required  Fields 

2a 

Name(s)  and  Year(s)  of  Proqram(s) 

2b 

Correct  Component/  System  for  program  is  addressed 

2c 

Name  of  Responsible  Engineer 

2d 

Name  of  Supplier  (Components),  if  Applicable 

2e 

Name  of  Component  Team  (Systems) 

2f 

Team  Members  are  identified  and  the  team  is  cross  functional 

2g 

Key  Date  Shown 

2h 

Date  of  original  FMEA  is  shown 

2i 

Revision  levels  &  dates  are  shown 

3 

Function  /  Parts  Column 

3a 

All  functions  are  identified,  including  manufacturability,  serviceability,  regulatory  legal  including 
all  functions  identified  in  the  Function  Model. 

3b 

All  identified  functions  have  measurable  requirements  per  specification. 
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4 

Potential  Failure  Modes  Column 

4a 

Failure  modes  match  functions 

4b 

Failure  modes  for  each  function  have  been  identified.  (For  Example,  "Inoperable,"  "Degraded 
Function/1  "Intermittent  Function,"  "Unintended/  Inadvertent  Function"  have  been  addressed) 

5 

Potential  Failure  Effects  Column  &  Severity 

5a 

Potential  effects  of  failure  describe  the  customers  experience 

5b 

Severity  index  rating  is  appropriate  for  the  most  severe  potential  effects 

5c 

Safety  and  regulatory  concerns  are  rated  with  a  severity  of  "9"  or  "10" 

5d 

Potential  Safety  items  with  causes  that  are  susceptible  to  mfg.  variation,  are  identified  with  an 
"S":  Regulatory  items  are  identified  with  an  "R";  KPPs:  KSAs,  KCCs,  KPCs,  etc  are  identified 
accordingly  in  the  Classification  column 

5e 

Descriptions  of  effect  include  impact  on  intermediate  ''customers’1  like  Assemblers,  Service 
Techs 

5f 

Potential  Effects  are  sufficiently  detailed  (not  'doesn't  work") 

6 

Potential  Causes 

6a 

All  failure  modes  have  at  least  1  cause 

6b 

Indicates  root  causefs)  of  the  identified  failure  mode 

7 

Current  Design  Controls  -  Prevention 

7a 

Prevention  Controls  refer  to  specific  simulations,  GD&T  studies,  analyses.  TD  testing  actions, 
etc. 

7b 

Prevention  Controls  include  specific  requirements  from  Engineering  Standards,  use  of  best 
practice  design  guidelines,  analysis  of  surrogate  data,  lessons  learned  and  prior  product 
history. 

7c 

Prevention  Controls  impact  the  Design  Release 

7d 

Prevention  Controls  include  Error/Mistake  proofing.  Design  for  Manufacturability/  Assembly  of 
product,  process  capability  data,  as  applicable. 
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8 

Occurrence  Column 

8a 

Each  cause  is  rated  separately 

3b 

Each  cause  has  at  least  1  Prevention  Design  Control.  (If  there  are  no  Prevention  Controls, 
then  Occurrence  is  automatically  rated  as  a  '"IQ"} 

Be 

Occurrence  ranks  the  effectiveness  of  Prevention  Controls  in  eliminating  the  Root  Cause  from 
the  Design  Release 

3d 

Occurrence  ranking  considers  the  likelihood  of  the  cause  occurring  over  the  entire  design  life  of 
the  product 

9 

Current  Design  Controls  -  Detection 

9a 

Design  Controls  refer  to  specific  tests,  analyses,  actions,  etc.  that  take  place  during  TD  and 
EMD  phases 

9b 

Each  cause  has  at  least  1  Detection  Design  Control.  (If  there  are  no  Detection  Controls  for  a 
Potential  cause,  then  Detection  is  automatically  rated  as  a  "10"} 

9c 

Design  Controls  do  not  include  production  process  controls 

9d 

Detection  Controls  are  applied  in  a  timely  manner  in  order  to  avoid  the  inclusion  of  the 
cause/failure  mode  in  a  Customer  Built  product 

10 

Detection  Column 

10a 

Detection  ranks  the  likelihood  that  the  cause  /  failure  mode  would  be  detected 

10b 

Detection  ranking  reflects  the  timeliness  of  the  application  of  the  Detection  Control.  (The 
detection  will  result  in  a  revised  design  prior  to  the  EMD  build). 

11 

Risk  Priority  Number 

11a 

RPN  appears  realistic  &  not  artificially  low.  Ranking  values  can  be  substantiated. 

11b 

RPN  was  calculated  correctly 
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12 

Recommended  Actions  &  Responsibility 

12a 

Highest  RPNs  and  Severity  Rankings  comprising  a  rolling  top  20%;  or  top  issues  as 
determined  by  DFMEA  Review  Team,  are  addressed  with  needed  actions 

12b 

Severity  Ratings  of  3.  9  or  10  are  given  special  consideration 

12c 

Recommended  Actions  are  assigned  to  a  named  person  w /  target  dates 

12d 

Key  characteristics  have  a  Current  Design  Control  or  a  Recommended  Action  to  ensure  or 
verify  that  they  are  addressed,  for  example,  in  a  PFMEA.  Engineering  drawings.  Standard 

Work  Instruction 

12e 

Recommended  Actions  may  not  be  left  blank.  If  actions  are  not  needed.  "None"  and  a 
statement  such  as  11  Risk  to  customer  is  very  low  due  to  experience  with  surrogate  products'1 
or '‘Currently  there  are  no  earlier  detection  controls  which  would  reduce  risk  to  the  program/1 41 
Risk  to  customer  is  very  low  due  to  high  likelihood  that  TD  phase  testing  is  very  likely  to  detect 
a  potential  Failure  Mode. 

12f 

Predicted  RPN  are  effected  by  Occurrence  and/or  Detection,  unless  a  design  change  mitigates 
the  Failure  Mode  and  Effect  of  Failure 

I2g 

Predicted  RPNs  are  stated  in  the  Recommended  Actions  column,  not  in  the  Action  Results 
column 

13 

Actions  taken 

13a 

Actions  taken  and  Target  Completion  Dates  are  shown 

13b 

Completion  of  Recommended  Actions  is  timely,  RPN's  have  been  updated  and  level  of  risk  is 
acceptable 

14 

Analysis  of  Findings 

14a 

Highest  Risk  Potential  Causes  of  Failure  Modes  are  identified  in  a  Pareto  Analysis/chart, 
which  is  created  and  attached  as  the  summary  cover  page  of  the  DFMEA 

TECHNOLOGY  DRIVEN.  WARFIGHTER  FOCUSED. 


Unclassified 


121 


rdecom^  DFMEA  Evaluation  Checklist 


Additional  DFMEA  Information  for  Lead  Engineer  and  Team  members: 

> 

Requires  the  use  of  standard  DFMEA  format,  ranking  scale  definitions  (which  have  been  tailored  by  the  FMEA  IPT  for  DoD  application  and  can 
be  further  tailored  by  the  specific  FMEA  teams)  and  reference  materials,  provided  in  the  Automotive  Industry  Action  Group  (AIAG)  FMEA 

Manual 

:> 

Team  should  review  this  form  while  developing  the  DFMEA  &  evaluate  DFMEA  prior  to  submission  for  approval. 

> 

When  there  is  an  "S"  in  the  Class  column,  the  DFMEA  team  should  communicate  the  significance  of  the  characteristic  to  Manufacturing 
(e.g..  through  the  drawing  and/or  that  it  is  addressed  in  the  PFMEA) 

> 

The  approved  DFMEA  should  be  updated  with  the  latest  TEMP  results  (i.e..  new  Failure  Modes.  Causes.  Design  Controls  identified,  etc.)  and 
any  Actions  Taken 

> 

DFMEAs  should  be  reviewed  at:  Technical  Reviews  and  Milestones  to  ensure  the  inclusion  of  the  latest  test  results  &  completed 

Recommended  Actions  before  product  launch  and  whenever  changes  are  written  for  the  component  or  system. 

Design  FMEA  Review  Log:  Comments  &  Program  Phase  j  Date  Reviewed  /  Reviewer 
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rdecom^  PFMEA  Evaluation  Checklist 


"Proaram  Name"  Process  FMEA  Basics:  Audit  Summary 

Name  of  Component  Suh-System  or  System: 

Responsible  Engineer  &  Facility  Name 

Quality  Auditor: 

Date  Reviewed: 

Accept.  Consistent  Adherence  to  FMEA  Criteria 

Revision  Required. 

Yes 

No 

Comments 

1 

la 

1b 

1c 

Id 

1e 

If 

ig 

1h 

Does  the  Header  Contain  Adequate  Information  ? 

Name  of  Program(s) 

Year  of  Program(s) 

Component!  System  is  included  in  Program 

Name  of  Contractor 

Name  of  Contractor  Team  &  Plant  (Assembly) 

Key  Date  Shown 

Date  of  original  FMEA  is  shown 

Revision  levels  &  dates  are  shown. 

2 

2a 

2b 

2c 

2d 

Is  the  Process  Steps  Column  Adequate? 

Process  steps/  work  stations  are  clearly  identified 

Tests  and  inspections  are  indicated  in  process  flowchart 

Each  operation  is  (briefly)  described,  rather  than  just  numbered 

Separate  in-line  inspection  stations  are  shown  as  process  steps 
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3 

3a 

Potential  Failure  Modes  Column  Adequate? 

Failure  modes  logically  match  process  steps 

3b 

Each  process  step  has  at  least  1  potential  failure  mode 

4 

4a 

4b 

4  c 

Potential  Failure  Effects  Column  Adequate? 

Effects  include  those  impacting  warfighter,  employees,  equipment 

Severity  index  is  appropriate  for  potential  effects 

Safety,  Regulatory  characteristics  are  rated  with  a  9  or  10 

5 

Potential  Causes  Column  Adequate? 

5a 

5b 

5c 

5d 

5e 

All  Safety  items  are  addressed 

Each  Failure  mode  must  have  at  least  1  cause 

Each  cause  is  rated  separately 

Occurrence  index  logically  rates  causes 

Assembly  &  processing  concerns  are  evaluated 

5f 

5g 

5- 

Potential  equipment  malfunction  is  included 

Selection  of  wrong  parts,  #  of  parts,  machine  settings,  etc  included 

Specific  deficiencies  are  indicated,  i.e.  widget  installed  upside  down 

5i 

Failure  mechanisms  for  Safety.  Regulatory,  KPP.  KSA.  KCC.  KPC 
are  indicated 
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6 

6a 

6b 

6c 

6d 

6e 

6f 

6g 

Current  Controls  Column  Adequate? 

Current  Controls  are  evaluated  separately  by  cause 

Each  cause  has  at  least  1  process  or  design  tor  assy,  control 

Detection  index  logically  rates  adequacy  of  process  controls 

Controls  include  part  fixtu ring,  visual  aids:  limit  switches,  etc. 

Process  Controls  do  not  just  include  "operator  training". 

Process  Controls  include  Mi  stake  proofing 

Controls  evaluated  per  experience  w/similar  production  lines/equip. 

7 

7a 

7b 

7c 

Risk  Priority  Number  Logical? 

RPN  is  realistic 

RPN  is  not  kept  artificially  low 

RPN  is  correctly  calculated. 

8 

3a 

3b 

8c 

8d 

Recommended  Actions  &  Responsibility  Columns  Reasonab 

e? 

High  RPN s  are  addressed  with  needed  actions 

Severity  Ratings  of  9  or  10  are  addressed 

Recommended  Actions  are  assigned  to  a  specific  person 

Targe!  Completion  dates  are  shown 

9 

9a 

9b 

9c 

9d 

9e 

9f 

Action  Results  Effectively  Executed? 

All  actions  taken  are  shown 

Actions  were  completed  in  a  timely  manner 

Actions  include  additional  tests,  inspections,  mistakeproofing,  etc 

Re-ratings  were  completed  and  reasonable 

Re-calculated  RPN  number  now  indicates  low-medium  risk 

High  risk  failures  are  taken  seriously 
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10 

10a 

10b 

f  10c 

f  IQd 
lOe 

lOf 
[  10g 
[  lOh 
lOi 
lOj 
10k 

101 

10m 

lOn 

lOo 

lOp 

Additional  Guidelines 

Comments 

PFMEA  seems  to  be  a  decision  making  tool 

Document  appears  to  be  a  living  document 

Current  Controls  operationalized  in  Process  Control  Plan  &  SOPs 

Key  characteristics  noted  in  DFMEA  are  conveyed  to  PFMEA 

PFMEA  has  been  updated  as  experience  is  gained 

Response  to  high  risk  failures  is  a  priority 

Detailed  Process  Flow  Chart  is  attached 

"Operator  Error*  is  not  the  only  (catch  all}  potential  cause 

"Supplier  &  out  of  spec  components  are  not  catch  all  causes 

"Visual  inspection"  rated  high  because  it's  ineffective 

"No  build"  assy,  (in-station)  rated  low  because  it's  very  effective 

In-station,  aided  inspection  rated  better  than  end  of  line  inspection 

Detection  in  subsequent  station  better  than  end  of  the  line 

Incoming  inspection  of  components,  is  rated  high 

Line  start-up  procedure  &  thorough  workstation  review  is  rated 
moderately 

If  equipment  failure  is  cause,  preventive  maintenance  is  good  control 
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Questions?  Contact  us 


The  following  TARDEC  representatives  can  answer  your  questions 

concerning  the  use  of  FMEA: 

Kadry.W.Rizk.civ@mail.mil 

Rebecca.L.Addis.civ@mail.mil 

Lisa.J.Graf2.civ@mail.mil 


RISK  RECON  WEBSITE:  https://risk  recon.army.mil 
RISK  RECON  HELP  DESK  EMAIL:  usarmv.detroit.peo-gcs.mbx.risk-recon-helpdesk@mail.mil 

RISK  RECON  HELP  DESK  PHONE:  586-219-6096 
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